profit/lakehouse
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

audit docs: deprecation headers — over-scoped for local-only deployment

Browse Source 
Today's PRD-line-70 reframe (everything runs locally) means the audit-trail
docs I drafted earlier this session are over-engineered for J's actual
deployment model. They were sized for SaaS-tier infra (Vault/KMS/S3
Object Lock/dual-control JWT/separate Postgres) — appropriate for a
multi-tenant cloud service, wrong for a single-box local install.

Adding clear deprecation headers so future sessions don't read these
as authoritative and propose another 17-20 day plan involving cloud
infrastructure that would re-violate PRD line 70.

What STAYS valid (preserved in headers):
- The legal use case (John Martinez worked example)
- The IL/IN jurisdictional surface (counsel checklist)
- The Phase 1 + 1.5 discovery findings (PII flow paths file:line)
- Phase 1.6 BIPA gates (when real photos arrive)

What's OVER-SCOPED (flagged in headers):
- The 9-phase implementation plan
- The identity service design (Vault/KMS/dual-control)

Future v2 of these docs needs to be sized for local single-box: a few
hundred LOC of local writers + signed local audit file, not 17-20 days
of distributed-systems design.

No code changes. Just doc-level guardrails for future scope drift.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
root
2026-05-03 02:42:05 -05:00
co-authored by Claude Opus 4.7
parent 5f40b7a312
commit dbcd05c5c5
2 changed files with 26 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/AUDIT_TRAIL_PRD.md
+16
View File
@@ -1,5 +1,21 @@
# PRD: Production-Ready Audit Trail
> **⚠ OVER-SCOPED — 9-phase plan needs to shrink for local-only deployment.**
>
> 2026-05-03 evening: J reframed the system as local-only per PRD line 70. The 9-phase plan in §8 was sized for SaaS-tier infrastructure with cloud HSM, separate identity daemon, dual-control JWT, etc. For a single-box local deployment, audit trail can be a few hundred LOC of local writers + a signed local file, not a 17-20 day phase plan.
>
> **What stays valid:**
> - The legal use case (worked example: John Martinez at Warehouse B requests audit) — this is the real problem
> - The §10.5 jurisdictional surface (IL BIPA, IN, federal) — counsel reads this
> - The §3 surface map: where decisions get made today (file:line evidence — see `AUDIT_PHASE_1_DISCOVERY.md`)
> - Phase 1.6 BIPA pre-launch gates — those still apply when real photos arrive
>
> **What's over-scoped:**
> - The 9-phase implementation plan (§8) — should compress to 3-4 phases for local-only
> - The identity service design (`IDENTITY_SERVICE_DESIGN.md`) — see that doc's deprecation header
>
> Do NOT execute the §8 phase plan as-written. When J greenlights, draft a v2 plan sized for local single-box.
**Status:** Draft — 2026-05-03 · **Owner:** J · **Drafted by:** working session 2026-05-03
> **Why this document exists.** Staffing client won't sign until we can prove the AI system can defend a discrimination claim. We've been claiming "production-ready" off smoke + parity tests; those prove the surface compiles, NOT that an audit response can be produced for a specific person. This PRD writes the audit-trail capability down before we start building it, so the phases are accountable and the scope doesn't drift mid-implementation.