coulomb/audit-core
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

AUDIT-WP-0010 T01/T03/T04 — admit tenant-engine, and the envelope does not match

Browse source 
Registration: attributive, with the declared completeness_trade recorded on the
receiver side rather than only in the emitter, per §9.6's requirement that the
trade travel with the trail. tenants ["*"] is justified rather than inherited —
tenant-engine's events carry the affected tenant, the set is every tenant
including ones created later, and an explicit list would fail closed at exactly
the moment a tenant is provisioned, dead-lettering the creation evidence of the
tenant whose creation it is. source stays pinned exactly. Ingress ANDs namespace
and pod label; a weaker evidence class is not a reason for a wider network rule.
All inert until the token exists.

Then the finding T04 existed to find: tenant-engine cannot deliver a single
event today. envelope_for sends five required fields under other names —
event_id, action, resource, observed_at, details — and omits correlation_id
entirely, so normalize() raises invalid_event. Verified by running the real
envelope through the real function, not by reading.

Worse than an ordinary integration bug. The drain treats 400 as terminal, so the
outbox row is marked handled while audit-core holds only a dead letter, which is
not chained and is not custody. Lost on both sides, and since the drain is
non-blocking and attributive, nothing fails loudly — a silent total loss of the
stream presenting as a working integration.

Taking the correction the intake invited rather than accepting a lossy record.
normalize() is NOT relaxed to accept the alternate spellings: a receiver that
guesses which sender key means which stored field has made the mapping its own,
and the record stops being the sender's assertion. correlation_id cannot be
synthesized at all — an invented one ties an event to an operation audit-core
never observed.

Root cause is ours. The accepted envelope was published nowhere a sender could
read it; audit-backend-contract.md describes the stored record, and a sender
reading it would reasonably infer exactly the names tenant-engine used.
schema_version audit-core.event.v1alpha1 selects nothing here and gave a false
impression of a negotiated contract. Published docs/event-envelope.md as the
wire contract, including the point that a 400 means the event is not in the
archive and must be treated as a defect to fix rather than a delivery outcome.

T05 moved to wait: nothing to prove end to end until an event can be accepted.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Nb7Q6ZmXppNDkTWytfYqfv

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2069992@bnt-lap001
Assistant-Session: 167dd7f8-2a25-4be1-aa46-3b6f1a5f94c6
This commit is contained in:
tegwick 2026-09-10 16:34:45 +02:00
parent e0505af3b5
commit 3c2cdcdf79
10 changed files with 610 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

67
workplans/AUDIT-WP-0010-tenant-engine-sender-admission.md
View file

@ -4,7 +4,7 @@ type: workplan
title: "Admit tenant-engine as an attributive sender"
domain: infotech
repo: audit-core
status: ready
status: active
owner: claude
topic_slug: railiance
created: "2026-08-29"
@ -49,10 +49,20 @@ validated, not when events start arriving.
```task
id: AUDIT-WP-0010-T01
status: todo
status: done
priority: high
state_hub_task_id: "e26170e3-78f1-5d98-bb8f-46cef32244bb"
```
Done 2026-09-10. `deploy/senders-scope.{json,yaml}`, recorded in
`docs/tenant-engine-source-registration.md`. `evidence_kind: attributive` with
the declared `completeness_trade` carried on the identity, so §9.6's
"declared where the trail is documented" is satisfied on the receiver side and
not only in the emitter. `tenants: ["*"]` is justified rather than inherited:
tenant-engine's events carry the *affected* tenant, the set is every tenant
including ones created later, and an explicit list would fail closed at exactly
the moment a tenant is provisioned — dead-lettering the creation evidence of
the tenant whose creation it is. `source` stays pinned exactly, asserted by
test. Inert until the token exists.
Register the sender identity: name `tenant-engine`, `sources: [tenant-engine]`,
`may_write: true`, `may_read: false`, `secret_policy: redact`, tenants scoped as
the envelope requires. Follow the existing `user-engine` shape in
@ -72,10 +82,21 @@ transport a value through State Hub messages.
```task
id: AUDIT-WP-0010-T03
status: todo
status: done
priority: high
state_hub_task_id: "1a75fba2-a625-5e87-bba9-e38f010856fc"
```
Done 2026-09-10. `audit-core-tenant-engine-ingress` in
`deploy/networkpolicies.yaml`, namespace AND pod label in one peer. Attributive
rather than load-bearing changes what may be claimed of the stream, not how
narrow its reachability should be — a weaker evidence class is not a reason for
a wider rule, so this follows approval-engine rather than user-engine's older
namespace-only breadth.
The workplan asked that a future third sender fail the test rather than fail
silently in production. `test_every_sender_has_exactly_one_ingress_rule` does
that by deriving the expected set from `senders-scope.json`: the policy set and
the registered sender set can no longer grow independently.
Extend the NetworkPolicy. `deploy/networkpolicies.yaml` currently admits
`user-engine`; add `tenant-engine`. `tests/test_networkpolicies.py` exists —
extend it so the second sender is asserted rather than assumed, and so a future
@ -83,10 +104,42 @@ third sender fails the test rather than silently failing in production.
```task
id: AUDIT-WP-0010-T04
status: todo
status: done
priority: medium
state_hub_task_id: "56bde19e-6b54-5d9e-a3d7-8b13e810cb51"
```
Done 2026-09-10 — and it found the thing the task existed to find.
**tenant-engine cannot deliver a single event today.** `envelope_for` emits a
shape `normalize()` rejects: five required fields are sent under other names
(`event_id`/`action`/`resource`/`observed_at`/`details` for
`id`/`type`/`subject`/`occurred_at`/`data`) and `correlation_id` is absent
entirely. Verified by running the real envelope through the real `normalize()`,
which raises `invalid_event`. Every event would 400 and dead-letter.
Worse than an ordinary integration bug, because tenant-engine's drain treats
400 as terminal. The outbox row is marked handled while audit-core holds only a
dead letter — not chained, not custody. The event is lost on both sides, and
since the drain is non-blocking and attributive, nothing fails loudly: a silent
total loss of the stream presenting as a working integration.
Taking the correction the intake invited rather than accepting a lossy record:
`normalize()` is **not** being relaxed to accept the alternate spellings. A
receiver that guesses which sender key means which stored field would be
inventing the mapping, and a record whose field meanings the archive chose is
no longer the sender's assertion. `correlation_id` especially cannot be
synthesized — an invented one ties an event to an operation audit-core never
observed.
**Root cause is ours.** The accepted envelope was published nowhere a sender
could read it; `docs/audit-backend-contract.md` describes the stored record, and
a sender reading it would reasonably infer exactly the names tenant-engine used.
`schema_version: audit-core.event.v1alpha1` selects nothing here and gave a
false impression of a negotiated contract. The wire contract is now published:
`docs/event-envelope.md`.
`tests/test_tenant_engine_envelope.py` pins the mismatch, the corrected
envelope, and the decision not to relax the receiver.
Validate the envelope against what `tenant-engine` actually sends:
`schema_version: audit-core.event.v1alpha1`, `tenant` = affected `tenant_id`,
`action` = domain event type, `resource` = `tenant:<id>`, duplicate event ids
@ -101,10 +154,14 @@ so the §9.6 trade is documented here and not only in the emitter.
```task
id: AUDIT-WP-0010-T05
status: todo
status: wait
priority: medium
state_hub_task_id: "777bb728-4a4d-5c5b-8b62-24fdb6ab31e3"
```
**Waiting**, re-statused 2026-09-10. Blocked on the T04 envelope correction in
tenant-engine, then on the T02 token. There is nothing to prove end to end
until an event can be accepted at all; running this now would only reproduce
the dead-letter path already covered by test.
Prove it end to end against the production receiver: a real event from
`tenant-engine` accepted, attributed to the right tenant, redacted per policy,
and linked into the chain. Record the evidence under `docs/evidence/`. Then