Evaluating Phalanx
Follow the action all the way to its outcome.
To evaluate an execution-control system, inspect what the agent proposed, what authority it had, what the gateway decided, and what actually happened. Phalanx connects these stages so the boundary can be examined in a concrete workflow.
Current demo: Meridian baseline, before Phalanx enforcement.
Five questions for a meaningful evaluation.
| Question | What to inspect |
|---|---|
| Who authorized the task? | The authenticated actor, task scope, allowed actions, and limits supplied by the customer application. |
| What action was proposed? | The exact tool, target, destination, arguments, and relevant system state. |
| Why did it proceed or stop? | The recorded PERMIT, HOLD, or BLOCK decision and the applicable policy or unresolved condition. |
| Could it execute another way? | Credential isolation and coverage of equivalent routes to the protected action. |
| What happened afterward? | The connector result, verification outcome, and any uncertainty or partial completion. |
Test useful work and the conditions that should stop it.
A useful evaluation includes ordinary authorized actions as well as the boundaries around them. These are evaluation questions, not published pass-rate claims.
| Scenario | Required observation |
|---|---|
| An allowed action with valid state | It can proceed through the protected route and its outcome is recorded. |
| An action outside the task's resource or destination scope | It receives no execution permit. |
| A task limit has been consumed | A later action cannot ignore the shared task history. |
| Approval is required | The action stays on hold until the required authorized resolution and re-evaluation. |
| Required evidence is absent or unavailable | The action follows the contract's hold or block behavior without a silent permissive fallback. |
| State changes before execution | Required execution-time checks detect the relevant change and apply the contract. |
| A permit or operation is repeated | The test distinguishes rejected permit reuse from connector idempotency and uncertain-outcome handling. |
| An external system times out | The result is recorded as known or uncertain according to verification evidence; a timeout is not reported as success. |
Keep the result attached to the system that produced it.
A meaningful result identifies the Phalanx release, protected workflow, connector, authority and policy configuration, test conditions, and observed outcome. Customer qualification also checks the infrastructure and routes that make the boundary enforceable.
The public Meridian environment is a synthetic demonstration operated by Invarra. Its introduction identifies the current enforcement status. A demonstration is not evidence that an unrelated customer deployment has the same coverage or configuration.
The Meridian environment is open for exploration with synthetic business data. Phalanx enforcement is not active in the public demo yet.
Earlier research and runtime evaluations.
Earlier Phalanx work evaluated written-text jailbreak control and typed prompt-injection containment. Those results concern a previous runtime and different evaluation contracts. They are preserved as historical material and are not performance results for the Phalanx V1 execution gateway.
Decide what success must look like in your environment.
Start with an authorized action that should work, a boundary that must hold, and an outcome you need to verify. We can use those requirements to scope a Phalanx evaluation.