Answer

Does every change leave an audit trail and a trace?

Yes. Every mutation goes through a module service or a named workflow, and leaves an audit event and a step-level trace behind it (C-16). That routing is also what makes the approval refusal enforceable rather than advisory: a test asserts that an agent cannot make the human's decision (C-04). What the audit is not: it records what the process did under an asserted actor, so it is not a tamper-evident or externally attestable log and it is not a compliance control — no authentication ships behind the actor it records, so that actor is only as trustworthy as the verifier a deployment supplies (L-01).

What the ledger says, word for word

Each entry below is copied from site/claims.json, where it is bound to the evidence that holds it — a test file, a document, or a named repository fact — and to the limitation that travels with it. The answer above summarises these; these are the claim.

C-16

Every mutation goes through a module service or a named workflow, and leaves an audit event and a step-level trace behind it.

LimitAudit records what the process did under an asserted actor. It is not a tamper-evident or externally attestable log, and it is not a compliance control.

JTBD-02tests/workflow.test.jstests/action-runtime-semantics.test.jstests/event-bus-outbox.test.jsARCHITECTURE.mddocs/ACTIONS.md

C-04

The agent cannot approve on the human's behalf. A test asserts the refusal, so the boundary is a property of the system rather than a promise in a README.

LimitIn local-development mode the actor is asserted, not authenticated: no authentication ships, so an actor header there is not an identity. This holds a boundary against an honest agent, not against an attacker with network access.

JTBD-02tests/workflow.test.jsARCHITECTURE.md

L-01 · No authentication ships: the framework authenticates nobody.

Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim.

JTBD-15tests/production-spine.test.jstests/actor-fails-closed.test.jsdocs/PROJECT_STATUS.mdREADME.mdDECISIONS.mdcrm app inspect reports a productionPosture that refuses to be read as a readiness claim

Where this stops

Nothing on this page implies deployment readiness. The framework ships no authentication verifier; authorization is framework-enforced; tenant isolation is one tenant per application instance, not shared-database row tenancy. Read the exact repository posture before deployment. Every claim and every limitation is on one page, and the questions this project refuses to answer are published beside them.