# Intake implementation and dependency acceptance — 2026-10-03 Work record: INFD-WP-0005. These are requirements for owner implementation; this document grants no deployment or credential-custody change. Local implementation: `intake_service.IntakeService` is a separate WSGI app with only `POST /v1/memos`; `TokenReview` checks an injected Kubernetes response; `intake_approval.IntakeApprovalClient` sends create-only approval requests through a bounded transport. Store schema 3 migrates existing schema 1/2 databases and adds the submission ledger and integration outbox. Packet bytes, pinned memo, ready ledger and posed/notification jobs commit in one transaction. Terminal human dispositions queue hub resolution in their existing evidence transaction. `IntakeDeliveryWorker` and the optional scheduled runtime dispatch audit, notification and hub transports with leases, stable ids, bounded batches and a disabled-by-default write-back. Posed events use the ordinary immutable audit outbox, receipts, per-class reconciliation and readiness checks. No listener is composed into the deployed runtime yet; shipped registries are empty, so no caller is admitted. No live deployment occurred. ## railiance-platform — T05, T10 Existing request: `cd811073-d6db-41cf-8a57-10df0b360eab`. Deliver a reviewed deployment change with: - ESO custody for `platform/workloads/informed-decision/sitting-requester`, mounted read-only to the intake workload; exact-path read grant, sibling-path refusal, safe secret metadata handling and no values in evidence. - Separate private intake port and Service, absent from public ingress; NetworkPolicy admitting only registered submitter namespaces/service accounts. - TokenReview RBAC for the review workload, API-server CA verification and an authenticated, bounded TokenReview transport. Project submitter tokens for audience `informed-decision-intake`; do not reuse browser or audit tokens. - Project the reviewed JSON registries so removal is visible on the next request without image rebuild. Review additions independently of the admitted submitter. - Workload OIDC client-credentials exchange yielding only `approval:create`, subject `informed-decision`, platform tenant and service principal provenance. Bind it to `IntakeApprovalClient`; no approve/read/consume scopes. Acceptance: wrong audience, unknown SA, removed grant and absent custody fail closed; one approved dev pose creates one human-control draft. Record immutable image/config references and founder approval before any live change. ## access-engine — T06, T10 Existing request: `306bcdd2-4fe4-4ccf-8aac-590c2abe51c4`. Deliver the §5.2 attribute admission branch, generated class/submitter data, drift check, exact-record compatibility branch and versioned request/response fixtures. Confirm field placement for review_group, memo_class, intake_submitter, approval_requester, approval_human_control, memo_version, approval_id and approval_binding_digest. Keep human authentication-derived identity, verified groups and act-time MFA freshness. No view_hash in PDP context. The approval fact must be read live and matched to the memo pin independently of an allow. Acceptance: unknown class/submitter, requester mismatch, false human_control, digest mismatch and stale MFA refuse; existing exact-record memos still work. Consumer changes must update both policy request construction and Store's strict policy-observation context comparison, with live engine reads before checks. Do not activate consumer attributes against the current exact-only pin. Signed PDP attribution remains the separately declared FLEX-WP-0024 gap. ## approval-engine — T05 recovery and production close-down Existing request: `59c5ee82-c706-4432-bab4-24af64031d39`. Confirm native service creation response fields and optional requested_via. Provide idempotent creation or a lookup/recovery contract for lost create replies. Current local behavior reserves before POST: `creating` without a receipt returns `approval_create_unresolved` and never reposts. `created` with a persisted receipt can retry the atomic local load without creating another approval. An unresolved create needs owner-assisted receipt reconciliation; never manufacture a digest or infer approval state. Idempotent creation is a close-down requirement, not a condition on offline tests or initial dev rollout. ## audit-core — T07 Existing request: `23b670ac-809e-49bf-9233-e0b62cf0a039`. Completed locally by AUDIT-WP-0011 (`audit_core/ingestion.py` and sender registry). The registered contract accepts `informed-decision.memo.posed` for source informed-decision and tenant platform; accept the locally retained event envelope containing memo/approval ids, carried binding digest, authenticated forwarding submitter, memo class and submission digest. No packet, brief, or secret content. T07 now connects posed jobs to AuditCoreSink, preserving the original event id on recovery and duplicate receipts. The new class participates in readiness, reconciliation and optional 86400-second heartbeat. Actual receiver tests cover acceptance, lost replies and duplicate receipts. Sender custody and deployed receiver/version acceptance remain part of T10; owner-local registration is not deployment evidence. ## state-hub — T07, T08 Existing request: `e30dea31-90e3-4fc0-954a-ed8412b52aca`. Deliver forwarding with the projected intake-audience SA token, bounded envelope, stable idempotency key, durable retry and receipt retention. Owner commit `49eeddb` provides a dev-only forwarding fixture and retained notification receipts. `d61ba32` accepts governed memo booleans (`requires_new_bind`, `required_ack`, `sealed`) as boolean leaves; a cross-repo fixture submits the real p01 envelope and checks those values are preserved. Do not strip or coerce shared-schema binding fields. Pose/replay/conflict evidence exists in the dev fixture. Browser/PDP acceptance remains open. The fixture is unscheduled and does not choose/admit an account. Identify the actual SA and supply runtime forwarding to review into the submitter registry. Forwarding proves the hub identity; drafted_by remains visibly asserted. The dedicated endpoint `POST /informed-decision/notifications` accepts only id/question/class/submitter using our stable delivery id as Idempotency-Key. Its receipt and founder message commit in one transaction; the receipt is retained independently of generic write-key TTL. `HubDelivery` checks the delivery id, message UUID, all echoed metadata, accepted status and signed-in-overview reference; queued relay acknowledgements remain pending. Notifications carry only id/question/class/submitter; the signed-in overview is the authoritative review entry point. Confirm resolve semantics: terminal human accept/decline only; return/discuss and resolves: never do not resolve. A 409 must allow reading an existing resolution to correlate it. Delivery failure retains local evidence and retries; other-memo conflicts block for review. T07 binds hub transports and schedules IntakeDeliveryWorker in the runtime with explicit `intake_delivery` configuration. Generic resolution idempotency retention defaults to 14 days. A resolved decision refuses a repeated resolve and can be correlated by read after a 409; unreadable conflicts remain retryable. Queued or mismatched success responses are not delivery receipts. Keep INFD_HUB_WRITEBACK unset until deployment approval and end-to-end evidence. ## gate-house and founder — T09, T10 Reply `4a290496-5aa7-4488-a01d-f8fde925a54b` answers the doctrine check: no human act is required when posing. GH-DEC-2026-023 is still proposed; this reply is not a ratified decision or live rollout approval. Spec now records C1–C6 and F1–F3. Production close-down additionally requires authenticated drafting identity, independent list review, signed claims/receipts, volume budgets and retirement of exact-record admission after its memos become terminal. T10 resumes after T05–T08 acceptance and founder approval for the concrete rollout. Record dev positive/negative traces first, then one live human answer with audit and write-back receipts. The provisioning sitting's human binding was completed in INFD-WP-ADHOC-2026-10-03-T02 (p01 accepted with native engine and audit receipts); it does not approve a new intake rollout. ## Opt-in delivery configuration The private review runtime v1 file may include: ```json "intake_delivery": { "hub_origin": "http://state-hub.state-hub.svc.cluster.local:8000" } ``` Omitting this field preserves the existing runtime: no intake deliveries or new posed heartbeat are scheduled. Configuration uses the existing audit custody; it neither enables a listener nor grants submitter access. `INFD_HUB_WRITEBACK` still defaults off. Terminal resolution failures retain the human's existing evidence and pending delivery; they never repeat the human act. ## Verification Full suite with `INFD_AUDIT_CORE_SOURCE=/home/worsch/audit-core` and `INFD_STATE_HUB_SOURCE=/home/worsch/state-hub`: 452 passed, 65 skipped (optional Approval Engine/Flex Auth component fixtures are not enabled). Checks include posed receiver acceptance/lost-reply replay, immutable local evidence/counts, readiness refusal, notification contract/receipt matching, resolution retry on unreadable conflicts, explicit runtime configuration and the State Hub forwarder's governed-boolean refusal at `49eeddb`. No new tasks/workplans or live changes were created. T07 is complete locally; T05/T06/T08/T10 remain waiting and INFD-WP-0005 remains blocked. Boolean follow-up, same source roots: state-hub `d61ba32` delivers the real p01 envelope and preserves `requires_new_bind`, `required_ack`, and `sealed`. Focused intake tests: 46 passed, 3 skipped. A later full local run was 449 passed, 64 skipped, and 4 failed outside this change (`waitress` is not installed, and one access-token audience case in `test_browser_auth.py`). `git diff --check` passed for this follow-up. T08 stays waiting.