# HUB-WP-0012 owner integration continuation — 2026-09-28

Initial foundation committed and pushed: `3e38614`.

Implemented in the follow-up:

- Audit Core sender conforming to its real eight-field ingestion contract,
  authenticated with a distinct rotating credential, and requiring operational
  durable custody plus an explicit accepted/duplicate receipt before execution.
- Exact verified signed policy artifacts retained in the archive; secret-shaped
  decision fields fail closed before serialization. Refusals retain verified
  identity, action and request/resource digests where available.
- Explicit `SecuritySettings` + owner `FactSource` runtime composition, bounded
  HTTP calls, no proxy-environment inheritance, and runtime-owned client cleanup.
  Configuration alone cannot activate a missing authority implementation.

Validation:

- Full suite with `HUB_CORE_AUDIT_CORE_SOURCE=/home/worsch/audit-core`:
  **304 passed**, one existing TestClient deprecation warning, 52.56 seconds.
- Final focused owner/denial checks after enriching refusal attribution: **7 passed**.
- Source inventory unchanged and validated: 161 Hub surfaces / 48 platform rows /
  250 observed cluster objects.
- `uv build` succeeds; `git diff --check` passes.

Five opt-in owner-source cases use the actual Audit Core receiver:

1. Hub envelope accepted and exact evidence retained across storage reopen.
2. Unmodified development custody rejected before posting.
3. A lost receipt blocks execution even though the receiver holds the attempt.
4. Invalid sender credential creates no record.
5. Composed JWT verification, current facts, signed decision, real receiver
   ingestion and native Hub write; archived decision independently verifies;
   root entitlement withdrawal denies the next attempt.

These are local tests with synthetic identities, keys and sender registration.
SQLite is durable test storage, not operational production custody. A clearly
named test-only readiness fixture simulates that custody classification; no
live receiver admission, real root login or platform access is claimed.

The [owner review](../owner-access-integration.md) records concrete next gates:
User Engine's `platform:root` mapping, a non-provisioning immutable identity and
root-entitlement lookup (its `/api/v1/me` can create an account), authenticated
Tenant Engine caller admission, and actual Hub Audit Core sender custody.
`warden route show audit-core-senders --json` routes registry ownership to
ops-mason/OpenBao and is unresolved. No secrets were retrieved or grants changed.