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:

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