Testing an Agentic Governance Boundary: 7 + 27 + 24 Anthesis Scenarios

Most AI governance discussions start with principles. Engineers eventually need a more operational question:

What was the agent allowed to do, what prevented it from doing something else, and what evidence proves the decision?

That is the problem Anthesis is built around.

Anthesis is a deterministic governance boundary for consequential agentic effects. The Anthesis Governance Lab is the public, independently runnable proof surface for the evaluator contracts.

The important clarification is that there is not one monolithic “24 scenario demo.” The current public lab deliberately separates three different proof surfaces.

The 7 / 27 / 24 Model

The counts are independent. The 24 inference-integrity cases are not part of the 27 general demo scenarios.

That separation matters because each surface supports a different claim.

What Anthesis Is Trying to Govern

Agentic systems gain authority through things that actually change the world around them:

• tool invocation;
• specialist delegation;
• memory and context access;
• filesystem and process mutation;
• network and API calls;
• repository writes, merges, releases, and deployments;
• external communication;
• durable state changes.

Anthesis treats those effects as governed transitions rather than assuming that a capable agent is automatically authorized to act.

A common supervisor/specialist composition looks like this:

AI control plane
  -> supervisor agent
    -> Anthesis governance boundary
      -> policy decision / capability / approval
        -> specialist agents
          -> governed tools, memory, services, APIs
            -> evidence / outcome

The supervisor can reason and orchestrate. Specialists can perform bounded work. The consequential effect still needs an explicit authority path.

A Signed Evaluator, Not a Trust-Me Demo

The public Governance Lab does not require access to the private Anthesis source repository.

It acquires an immutable public anthesis-lab release from hackelia-micrantha/anthesis-community and verifies the release before executing it. The acquisition path checks the source-derived release identity, Sigstore producer identity, provenance, checksums, archive contents, binary identity, CLI version, supported contracts, and repository-contained install path.

On a supported Linux x86_64 environment, the basic setup is:

git clone https://github.com/ryjen/anthesis-governance-lab.git
cd anthesis-governance-lab

bash scripts/acquire-anthesis-lab.sh
export PATH="$PWD/.anthesis/bin:$PATH"

anthesis-lab version --format json | jq .

The point is not that a checksum makes governance correct. The point is that a governance demonstration should at least be able to identify which evaluator produced the result.

Proof Surface 1: Seven Canonical Governance Scenarios

The smallest public contract contains seven pinned scenarios.

Run them with:

set -o pipefail
anthesis-lab test --repo . --format json |
  jq '{version, passed, total, passed_count, failed_count}'

Expected result:

{
  "version": "anthesis.test-report/v1",
  "passed": true,
  "total": 7,
  "passed_count": 7,
  "failed_count": 0
}

These fixtures are intentionally small. They establish stable public semantics for:

• allowed work;
• approval-required work;
• policy denial;
• unknown-runtime engine-guard denial.

The canonical validation also performs an intentional expectation-drift exercise:

bash scripts/validate-governance-lab.sh

A copied fixture expectation is changed while the policy remains unchanged. The evaluator must detect the mismatch and return exit code 7.

That distinction is important: fixture expectations are assertions, not inputs that tell the evaluator what decision to return.

Proof Surface 2: Nine Packs, Twenty-Seven Broader Scenarios

Seven cases are enough for a compact conformance contract, but not enough to show the range of actions an agentic system may attempt.

The broader demonstration catalog contains nine packs with three scenarios each:

1. documentation
2. source-code
3. ci-and-release
4. dependencies
5. secrets-and-evidence
6. network-and-tools
7. runtime-and-identity
8. deployment-and-administration
9. adversarial

List the exact cataloged pack IDs:

bash scripts/run-demo-pack.sh --list

Run one pack:

bash scripts/run-demo-pack.sh adversarial | jq .

Or aggregate all nine:

bash scripts/aggregate-demo-packs.sh |
  jq '{classification, pack_count, passed_packs, total_scenarios}'

Expected aggregate result:

{
  "classification": "passed",
  "pack_count": 9,
  "passed_packs": 9,
  "total_scenarios": 27
}

These are declaration-evaluation scenarios. They do not actually merge branches, deploy software, publish releases, access secrets, or run arbitrary network operations.

That is deliberate. The lab is proving evaluator behavior safely, not pretending that synthetic declarations are production execution.

Proof Surface 3: Twenty-Four Inference-Integrity Scenarios

The inference-integrity suite asks a different question:

Given recorded evidence about an inference path, does the evaluator classify the verification strength, verdict, and required policy posture correctly?

Run it with its own command:

set -o pipefail
anthesis-lab inference-integrity --repo . --format json |
  jq '{version, passed, total, passed_count, failed_count}'

Expected result:

{
  "version": "anthesis.inference-integrity-report/v1alpha1",
  "passed": true,
  "total": 24,
  "passed_count": 24,
  "failed_count": 0
}

The current 24-case contract covers these scenarios:

The cases exercise several verification classes:

• fixed_seed;
• bounded_consistency;
• semantic_only;
• governance_only;
• unsupported.

They also distinguish verdicts such as conformant, suspicious, dangerous, and indeterminate from the policy posture Anthesis should take in response.

That distinction avoids collapsing “the evidence looks suspicious” into “the evaluator itself is allowed to execute a containment action.” Evidence informs governance; the surrounding runtime still owns the actual effect.

Determinism and the Negative Control

The executable inference validation does more than count 24 fixtures:

bash scripts/validate-executable-inference-integrity.sh

It requires:

• two JSON evaluations to be byte-identical;
• all 24 scenarios to pass;
• YAML output to remain valid;
• a copied expectation mutation to produce exactly one failed case;
• the controlled mismatch to exit with status 7.

Expected final line:

Inference-integrity executable suite: 24 passed; mismatch exit 7 verified

This is the part I care about most as an engineering test. A passing suite is useful. A suite that can also prove it notices deliberate drift is much more informative.

Reproducible Evidence

The inference-integrity demo can generate a small evidence bundle:

bash scripts/generate-inference-integrity-evidence.sh

The bundle contains the passing JSON/YAML reports, controlled mismatch report, manifest, and checksums.

Verify it with:

cd .anthesis/evidence/inference-integrity
sha256sum --check SHA256SUMS

The manifest binds the report to the evaluator/release identity, source revisions, report contract, scenario count, and controlled mismatch result.

What the Governance Lab Actually Proves

A successful run establishes that:

• a specific signed public evaluator was acquired through the documented trust chain;
• the seven canonical governance fixtures reproduce their expected deterministic decisions;
• all nine general demo packs and 27 scenarios reproduce their expected decisions;
• all 24 inference-integrity fixtures reproduce their expected verification results and policy postures;
• controlled expectation drift is detected rather than silently accepted;
• generated evidence can be checksum-verified.

That is a useful proof surface.

It is not the same thing as proving that an arbitrary AI agent cannot bypass Anthesis.

What It Does Not Prove

The public lab does not:

• execute the declared filesystem, command, network, merge, deployment, release, or administration effects;
• persist production approvals;
• invoke a live model provider for the 24-case fixture suite;
• independently replay a live provider response;
• execute containment or recovery actions;
• prove that arbitrary credentials, raw tools, network routes, or processes cannot bypass Anthesis.

The inference-integrity suite is explicitly fixture-only and provider-neutral. It can run without a GPU, model credential, live provider, or Dubnium service after the evaluator has been acquired.

That limitation is not a weakness to hide. It identifies the next boundary that has to be tested.

Where Dubnium Fits

Dubnium is the reference environment for the other half of the problem: making a governance decision authoritative at an execution boundary.

Conceptually:

agent request
  -> Anthesis decision and capability boundary
  -> exact approval when required
  -> bounded executor or runtime enforcement
  -> attributable evidence and outcome

Anthesis remains the policy authority. Governance Lab independently validates the public evaluator contract. Dubnium provides a place to test bounded tools, gateway metadata, execution identity, replay/verifier integration, containment, recovery, and the practical question of bypass resistance.

That separation avoids having the runtime certify its own policy semantics.

Six Things I Would Measure in a Real Trial

The public fixtures are only one part of evaluating a governance system. A useful trial against a real agentic workflow should measure:

1. Enforceability — can the effect occur without crossing the selected governance boundary?
2. Attribution — can the action be tied to the supervisor/specialist, runtime, tool, policy, capability, approval, and evidence?
3. Least privilege — do deliberately out-of-scope variants fail?
4. Human approval — does approval-required work remain blocked until the exact approved scope is granted?
5. Auditability — can the decision, execution, and outcome be reconstructed at the claimed verification level?
6. Bypass resistance — what raw tools, credentials, network routes, or runtime paths remain outside the governance boundary?

Those criteria matter more than simply adding more fixture rows.

Reproduce the Whole Public Demo

The Governance Lab now has a single full verification runbook that walks from a fresh checkout through:

• signed evaluator acquisition;
• 7 canonical scenarios;
• 9 packs / 27 general scenarios;
• 24 inference-integrity scenarios;
• negative controls;
• evidence generation and checksum verification;
• structural/catalog validation.

For a short presentation, use the five-minute walkthrough. It intentionally focuses on the basic governance story and treats inference integrity as an extension rather than trying to walk an audience through all 24 cases.

The Point

I do not think useful AI governance starts with trying to control an agent’s internal reasoning.

It starts by making authority explicit at the point where reasoning becomes consequence.

Then the questions become testable:

• What effect was requested?
• Which policy allowed or denied it?
• Was approval required?
• What capability was granted?
• What prevented a direct bypass?
• What evidence proves what happened?

The Anthesis Governance Lab is deliberately small enough to inspect and reproduce. The next step is not to make the demo sound more powerful than it is. It is to connect those deterministic contracts to increasingly strong execution boundaries and test whether the same invariants still hold.

References

• Anthesis Governance Lab — executable public demonstration repository
• Governance Lab full verification — complete 7 / 27 / 24 reproduction path
• Inference-integrity runbook — detailed 24-case interpretation and limits
• Anthesis Community — public contracts, documentation, and signed release distribution
• Anthesis website — project overview and integration model
• Anthesis Update: Memory, Governance, and Beyond the SDLC — earlier Anthesis direction
• Dubnium as Agentic Orchestrator — reference runtime context
• Git Execution Surface — related thinking about governed effects

Anthesis is under active private development. The public Governance Lab exists so the deterministic governance claims can be inspected without requiring access to the private implementation.