SITUSDemoDashboardMailboxesPolicyMandatesGrantsReceiptsVerifyPasskeysDocs

Docs

What Situs Pilot 1 is, and how to build against it.

From docs/INVARIANTS.md in the repository.

Invariants → the tests that prove them

The nine invariants in CLAUDE.md are enforced by code and proven by tests. Each entry names at least one test as path::test_name. tests/test_docs.py fails if any named test disappears or if an invariant loses its last test.

Run them all:

make test                       # everything in-process (integration tests skip)
make up && uv run pytest -m integration   # the live end-to-end test

1. No ambient authority

The agent never holds a bank credential. Only the enforcement point's secret broker does, and only after a valid grant.

2. Classification is not authorization

Model output never widens scope or mints a grant. A fooled model can propose anything; only the deterministic policy decides.

3. AI never creates authority

The Authority Engine is deterministic and makes no model call.

4. Complete mediation for covered actions

bank.executeTransfer is reachable only through the enforcement point. The demo-bypass path exists only to show what happens without Situs, and it is labeled.

5. Discovered credentials are data

A credential string in a document or in model context is never used.

6. Single-use Action Grants with an idempotency key

The bank enforces idempotency.

7. Revocation is first-class

Revoking an Intent Contract makes later grants impossible. The receipt shows the status as of verification time.

8. Each fact is signed by the party responsible for it

Principal over the Intent Contract, approver over the action hash, enforcement point over the decision, counterparty over the acknowledgment (receipt 0.3: signatures.counterparty, kid from the plugin's connector.json; the demo bank for treasury). The acknowledgment is bound to the action hash and the grant's idempotency key inside the counterparty's own signed body, and the verifier's check 6 requires both. Situs signs only the assembly.

9. Every receipt states what is proven and what is not

The attestation slot is L1-sim in this build. The hardware quote fields are present and empty.

10. Plugin neutrality

Nothing under situs_core/ (except situs_core/plugins/ and the bundles), services/authority/, services/pep/, services/gateway/, services/console/ or cli/ names a plugin's domain. Every plugin declares a vocabulary; a plugin never imports from services/; core never imports a specific plugin. The enforcement point loads a plugin's declarations only (façades, profile, connector.json) and runs no plugin code.

Core's own words (Task 34, docs/DECISIONS.md D34): a vocabulary word core also uses in a sense of its own (record, release, purpose, recipient; situs_core/plugins/glossary.py) may appear bare, and joined to other words only in the compounds the glossary lists. Every other vocabulary word is scanned as before.

11. Plugin narrowing

If core denies, the outcome is deny whatever the plugin says. A plugin decides deny, escalate or pass. The covered façade needs approval unless the signed profile envelope sets approval.delegate_to_plugin: true, and the receipt records that delegation.

12. Approval assurance

An approval is accepted only if its signature verifies against a key enrolled for that approver at an assurance level at least as high as the route demands (software, hardware, hardware_attested). The receipt records the level achieved. No app, channel or console can lower it.