Monterey Phoenix’s Completeness Guarantee

What makes Monterey Phoenix (MP) different — and why it matters for high-stakes systems

Most modeling approaches explore a subset of system behavior; they generate selected paths — expected scenarios, representative cases, or behaviors that have been explicitly defined. MP does something fundamentally more powerful: It generates the scope-complete set of behavior traces your model permits— every valid combination of events — up to a user-defined scope limit.

What “scope-complete” means

In MP, system and environment behaviors are defined using a small set of compositional rules based on two primary relations:

  1. precedence: events occurring in sequence
  2. inclusion: events containing other events

Events are grouped inside logical structures denoting concurrent, alternative, optional, and looping events. Additional constraints are imposed only where necessary.

“For a given MP schema it is possible to obtain all valid traces up to a certain limit. Usually such a limit (scope) may be set by the maximum total number of events within the trace, or by the upper limit on the number of iterations in grammar rules.”

Dr. Mikhail Auguston, “Behavior Models for Software Architecture” (2014)

When you run the model, MP’s event trace generator automatically produces every execution path that satisfies those rules. This generation is exhaustive within a defined scope:

  • For models without iteration, the set of event traces is complete, without qualification.
  • For models with iteration, scope-complete guarantees that every valid combination of events up to the defined limit is included.

No behavior the model permits within that scope is excluded.

This is a lightweight formal method: exhaustive behavioral coverage of the specification, without the high cost and expertise usually attached to formal verification.

Why this matters in practice

Most modeling tools and diagrams (including SysML sequence and activity diagrams) represent selected behaviors. That makes it hard to see the full set of outcomes a specification may still permit. MP surfaces that whole set of permitted behaviors — including unexpected and unwanted extra behaviors that emerge from interactions.

When teams inspect generated traces — often beginning with small scopes (for example, 1–3, where many meaningful behaviors already surface) — they can identify:

  • Expected behaviors → verify they’re present
  • Unexpected yet plausible behaviors → test assumptions and constraints
  • Unwanted behaviors → add targeted constraints (which become formal requirements) to chip them away, like a sculptor removing marble to reveal the form inside

This process turns knowable unknowns into documented, testable requirements — before they surface in operations.

From knowable unknowns to explicit requirements

As behaviors are identified, teams introduce targeted constraints to eliminate unwanted outcomes. These constraints become explicit requirements. The process is iterative:

  • generate traces
  • inspect outcomes
  • classify behavior
  • refine constraints
  • repeat

Over time, this produces a more precise specification — one that documents each new constraint as the consequences of its absence are discovered.

Where the framework comes from

Developed at the Naval Postgraduate School, MP has been used by students and practitioners in systems engineering, computer science, cybersecurity, public policy, psychology, criminal justice, and other fields. Hundreds of students, from high school to graduate school, have learned it in weeks and found previously unseen failure modes in models of real systems. 

MP is the computational engine under Firelight Logic’s Emergeneering™ methodology: model behaviors and interactions separately (and minimally at first), generate the scope-complete set of traces, inspect with human reasoning, classify, and then control. The MP Ember™ platform is used to run MP and assist with trace analysis. The result is a tighter specification that keeps acceptable behaviors and removes the unacceptable ones.

For technical teams who want the full picture

Schedule a Conversation

Using MP expands the set of assertion checks and test cases by surfacing previously unknown unacceptable behaviors. Teams implement tighter and more precise constraints while still preserving a healthy range of acceptable behaviors that might otherwise have been cut too soon. This is not sampling. This is not “some scenarios.” This is every path the model permits, up to the scope you choose — so decisions can rest on what the rules allow.

Ready to see it on your system?

For Technical Teams Who Want the Full Picture

Using MP dramatically expands the set of assertion checks and test cases by surfacing previously unknown unacceptable behaviors. Teams implement tighter, more precise constraints—while still preserving a healthy range of acceptable behaviors that might otherwise have been over-cautiously eliminated.

This is not sampling.

This is not “some scenarios.”

This is every permitted path, up to the scope you choose—so you can make decisions with visibility into what your system actually allows.

Ready to see it in action on your system?

Start a Conversation

Bibltiography

Auguston, Mikhail. 2014. Behavior Models for Software Architecture. Technical Report NPS-CS-14-003. Naval Postgraduate School.

Giammarco, Kristin. 2023. “Exposing and Controlling Emergent Behaviors Using Models with Human Reasoning.” In Emergent Behavior in System of Systems Engineering, edited by Larry Rainey and O. Thomas Holland, 23–61. CRC Press.

Giammarco, Kristin. 2024. “System Behavior Specification Verification and Validation (V&V).” In Systems Engineering for the Digital Age: Practitioner Perspectives, edited by Dinesh C. Verma, 219–40. John Wiley & Sons.

Sutherland, Joshua, Alfonso Lanza, Kristin Giammarco, Michael Pennotti, Dov Dori, and Louise Harney. 2025. “Elegant Solutions to Complex Problems – Perspectives and Practice.” INSIGHT 28 (4).