Disciplines · Audits

Eve online outcome feedback preparation — 2026-09

Gap audits and as-built reviews.

0sections3 minread

On this page

Task 12.6 now has a production BFF authority for privacy-minimized online evaluation observations. It accepts only bounded identifiers, an exact evaluation-family ID, one or more offline case IDs, a control/shadow/canary cohort, and enumerated outcome facts. Raw prompts, responses, transcripts, notes, content, user IDs, tenant IDs, email addresses, and IP fields are rejected recursively instead of sanitized and retained. Event IDs are opaque 128-bit values; assignment uses HMAC and does not retain the subject key.

Outcome resolution is deliberately ordered: a downstream verified result has rank 5; correction or undo has rank 4; explicit human acceptance or rejection has rank 3; a thumb has rank 1; absence remains unknown. A positive thumb therefore cannot hide a verified failure, correction, undo, or rejection. Shadow traffic cannot claim user-visible acceptance, correction, undo, or thumb signals.

The durable store is wired into BFF boot as one immutable PostgreSQL row per event, rejects changed idempotent replays across replicas, caps storage, and enforces a 90-day minimized-event retention window. Indexed reads require one exact deployment, model leg, and control/shadow/canary cohort, avoiding both a growing JSON-snapshot rewrite and silent pooling in which healthy control traffic could hide a degraded canary. The reads observe rows from every BFF replica. Its admin-only intake and drift routes use the existing BFF authentication boundary. Drift is computed separately for all 15 Task 12.1 families from non-overlapping baseline/current windows using total-variation distance. A family requires 200 observations in each window and slice; below that floor the result is insufficient-data, never “stable.” The former whole-snapshot adapter remains only as a compatibility and isolated-test seam, not the production wiring.

The retained PostgreSQL service-integration receipt exercises the real local assistant_online_outcome table, closes and recreates database clients, and proves exact restart reconstruction, no write for rejected raw content, no retained raw canary value, replay idempotency, conflicting-replay refusal, physical expiry, restart after expiry, the exact privacy-minimized column set, the required slice index, and cleanup. Its strict schema fixes those observations to passing values. This is a local synthetic service boundary, not deployed shadow/canary traffic.

The retained local PostgreSQL operational exercise offered 7,200 events through four repository writers over 60,002.114 ms. It sustained 119.996 events/s with zero errors, 5.019 ms p95 and 9.356 ms p99 writes, 226,250,752 bytes of RSS growth, exact cleanup, and isolated the planted change to conversation while the other 14 families remained stable inside one exact control slice. The first attempt is retained separately: it met every functional, load, latency, memory, drift, and cleanup condition but honestly failed because timer jitter measured 59,999.223 ms, 0.777 ms below the preregistered 60-second floor. The runner was then changed only to await any remaining fractional duration; no threshold was relaxed.

These fixtures prove local synthetic store/detector and normalized PostgreSQL behavior only. Task 12.6 remains open until a deployed shadow/canary exercise, production-representative operational evidence, privacy/governance review, and genuine human/downstream outcomes satisfy every preregistered proof boundary. They must not be cited as production drift or human acceptance evidence. Offline case IDs are structurally required and retained, but admission against a complete family-result manifest cannot be claimed until that manifest exists; the contract-fixture IDs in the automated evidence are not represented as graded offline cases.