fix: report truthful compatibility outcomes and verify audit coverage

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0e747-8f27-7242-8df8-8bc44f88c929

docs/access-profile-v1.md

@@ -56,9 +56,9 @@ A host composes `create_app(access_controller=AccessController(...))` with:
   only after an operational-custody probe and explicit durable acceptance. Every allow must reach this sink before handler execution;
   a failed sink blocks reads as well as writes. Authorization receipts say
   `authorized`, not “operation completed.” Domain commit/outcome audit remains a
-  separate concern. Native durable mutations now have a
-  [transaction-linked outcome outbox](operation-outcome-audit.md); compatibility
-  and external mutations remain outside that slice.
+  separate concern. Native durable and implemented SQL compatibility mutations have a
+  [transaction-linked outcome outbox](operation-outcome-audit.md); arbitrary
+  embedded-host and external mutations remain outside that slice.
 - The root's existing immutable issuer and subject, supplied after owner resolution.
   No username, email, first-login promotion or generic role establishes root.
 

docs/operation-outcome-audit.md

@@ -1,4 +1,4 @@
-# Transaction-linked native operation outcomes
+# Transaction-linked operation outcomes
 
 HUB-WP-0012 source candidate, 2026-09-28. Live sender admission, database rollout
 and owner acceptance remain open.
@@ -26,8 +26,20 @@ retained separately from verified authorization correlation IDs. That verified
 ID and decision ID join the outcome to the pre-execution signed decision already
 held by Audit Core. The outcome does not duplicate the signed envelope.
 
-This slice covers the native durable mutation ledger. It does not claim outcome
-coverage for compatibility/embedded-host mutations, background projection refresh,
+Implemented SQL compatibility writes share this transaction boundary: hub,
+manifest create/update/activate, consumer, API key, widget and interaction-event
+writes, through both `/api/v2` and root aliases. Key issuance also updates the
+consumer in the same transaction; an outbox failure rolls both changes back.
+Generated keys never enter the ledger/outcome envelope and cannot authenticate
+enforced routes, which still require verified OIDC identity.
+
+Unimplemented token issuance and deferred POST operations return `501`, including
+in OpenAPI, rather than acknowledging a mutation that did not occur. Missing
+manifest update/activation returns `404`. Neither creates a committed outcome.
+Interaction responses return the persisted ID even when the caller supplies an ID.
+
+This does not claim outcome coverage for arbitrary embedded-host mutations,
+background projection refresh,
 external services, or in-memory development stores. Non-enforced maintenance
 writes retain their existing local ledger behavior without fabricating an actor
 or emitting an attributed remote outcome.
@@ -75,7 +87,7 @@ This document neither issues that grant nor claims production delivery.
 ## Local evidence
 
 Tests use SQLite-backed durable stores to prove atomic rollback, handler rejection,
-all native mutation families, actor/decision attribution, concurrent request
+all native and implemented SQL compatibility mutation families, actor/decision attribution, concurrent request
 isolation, persisted retry delay, reopen/replay, cancellation, stale-backlog
 readiness, dispatcher drain/shutdown and migration shape/downgrade refusal.
 The real Audit Core receiver/storage source accepts the eight-field envelope and
@@ -83,7 +95,8 @@ returns a duplicate receipt on replay. Its operational-readiness classification
 is explicitly a test fixture; this is not live custody evidence.
 
 Disposable PostgreSQL tests now verify multiworker lock scheduling, the full
-migration chain, rollback, persisted retries and process-exit replay. See the
+migration chain, native and compatibility-key rollback, persisted retries and
+process-exit replay. See the
 [PostgreSQL gate](conformance.md#disposable-postgresql-gate). Production grants,
 retention and deployed failure-detection/receiver acceptance still require receipts.
 

docs/owner-access-integration.md

@@ -46,8 +46,8 @@ at three seconds, uses TLS, and never follows redirects.
 Allow is blocked until the archive accepts the authorization record. A lost
 receipt blocks the business operation even if the attempt reached storage. This
 is a pre-execution authorization journal, not proof that an operation committed.
-Authorization cannot use a local success buffer or silent redaction. Native
-transaction outcomes now use a separate [durable outbox](operation-outcome-audit.md);
+Authorization cannot use a local success buffer or silent redaction. Native and
+implemented SQL compatibility transaction outcomes use a separate [durable outbox](operation-outcome-audit.md);
 its production delivery and broader mutation coverage remain T03/T04 gates.
 
 The exact verified signed decision is retained under `data.signed_decision` as