informed-decision/docs/intake-dependency-requirements.md

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:

"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.