ceo-orchestration 1.0.0

package/.claude/skills/domains/government/skills/digital-presales/SKILL.md

@@ -0,0 +1,359 @@
+---
+name: digital-presales
+description: >
+  Presales engineering for government and public-sector digital transformation
+  engagements. Covers the full lifecycle from policy signal interpretation and
+  opportunity qualification through solution architecture, bid documentation,
+  proof-of-concept validation, and post-award handoff. Operates across
+  multiple procurement jurisdictions — FedRAMP / GovRAMP / FISMA (US), eIDAS 2
+  / GDPR / NIS2 (EU), LGPD / Lei das Estatais 13.303 / Lei 14.133 (Nova Lei de
+  Licitações) + ICT procurement instructions (Brazil), and 等保2.0 / 国密 / 数据本地化
+  (China/APAC) — applying the same structural discipline to each. Includes
+  compliance matrix authorship, sovereign-cloud architecture tradeoffs, and
+  data-residency mandate mapping. Use when designing a presales workflow for a
+  public-sector engagement; reviewing a draft bid document for compliance
+  coverage; shaping a POC acceptance-criteria set; advising on
+  multi-jurisdiction data-residency architecture; or assessing go/no-go for a
+  government opportunity.
+owner: Augustina Ferreira (Government Digital Presales Lead, domain persona)
+secondary_owner: Tomasz Wierzbicki (Public Sector Compliance Architect, domain persona)
+tier: domain:government
+scope_tags: [presales, public-sector, bid-documentation, fedramp, eidas, lgpd, compliance-architecture]
+pii_handling: optional
+inspired_by:
+  - source: msitarzewski/agency-agents/specialized/government-digital-presales-consultant.md@783f6a72bfd7f3135700ac273c619d92821b419a
+    license: MIT
+    relationship: structural_inspiration
+    authored_by: ceo-orchestration framework
+    authored_at: 2026-05-07
+# --- smart-loading fields (PLAN-083 Wave 0b sub-agent 0.7c) ---
+domain: government
+priority: 8
+risk_class: medium
+stack: []
+context_budget_tokens: 700
+inactive_but_retained: true
+repo_profile_binding:
+  frontend: {active: false, priority: 10}
+  engine: {active: false, priority: 10}
+  fintech: {active: false, priority: 10}
+  trading-readonly: {active: false, priority: 10}
+  generic: {active: false, priority: 10}
+activation_triggers: []
+# --- K1 paths: native file-touch activation (PLAN-135 W3 unit k1a) ---
+paths:
+  - "**/bids/**"
+  - "**/rfp/**"
+  - "**/proposals/**"
+  - "**/compliance-matrix/**"
+  - "**/poc/**"
+---
+
+# Government Digital Presales
+
+## Cardinal Rule
+
+A bid commitment the implementation team cannot deliver under audit-grade
+scrutiny is a contract that must be lost, not won. Every technical claim in
+a bid document — architecture scope, performance metrics, compliance
+posture, staffing levels, timelines — must be traceable to evidence the
+delivery team can reproduce under protest or contract dispute. Over-promising
+to win creates a liability larger than the contract value.
+
+## Fail-Fast Rule
+
+If a mandatory compliance control (FedRAMP authorization boundary, LGPD
+data-minimization requirement, 等保2.0 Level 3 security domain, eIDAS
+trust-service qualification) cannot be mapped to a concrete product or design
+decision already in the solution architecture, **stop bid preparation and
+escalate**. A compliance matrix row that says "TBD" or "planned for Phase 2"
+for a mandatory control is a disqualification risk in every jurisdiction.
+Do not submit.
+
+## When to Apply
+
+- Qualifying a government or public-sector opportunity (go/no-go assessment).
+- Authoring or reviewing a technical proposal, compliance matrix, or SOW.
+- Designing a POC scope and acceptance-criteria set.
+- Advising on sovereign-cloud, on-prem, or hybrid architecture for a
+  government agency.
+- Mapping data-residency and cryptography requirements across jurisdictions.
+- Preparing a bid-document review for public-records exposure risk (FOIA /
+  sunshine laws).
+- Conducting a presales-to-delivery handoff.
+
+## Public-Sector Engagement Lifecycle
+
+```
+Pre-RFP intel
+    |
+    v
+RFI response (optional — shapes the RFP)
+    |
+    v
+Solution shaping (architecture + compliance mapping + partner alignment)
+    |
+    v
+RFP response (technical proposal + compliance matrix + past performance +
+              pricing + risk register)
+    |
+    v
+POC / technical evaluation (if required by the procuring agency)
+    |
+    v
+BAFO — Best and Final Offer (if multi-round procurement)
+    |
+    v
+Award / contract execution
+    |
+    v
+Presales-to-delivery handoff (commitments transfer + knowledge transfer)
+```
+
+Each gate has a hard exit condition:
+
+| Gate | Hard exit |
+|------|-----------|
+| Pre-RFP intel | Budget not confirmed, no clear timeline → monitor only |
+| Solution shaping | Mandatory compliance control unresolvable → no-bid |
+| RFP response | Disqualification risk in qualifications section → no-bid |
+| POC | Acceptance criteria not agreed in writing before start → defer start |
+| BAFO | Price below cost floor → withdraw or accept loss on record |
+| Handoff | Delivery team cannot confirm they own all presales commitments → escalate before contract signing |
+
+## Multi-Jurisdiction Compliance Frame
+
+Every government engagement must identify the applicable compliance frame
+before solution architecture begins. The table below covers the four primary
+lanes. A single engagement may span multiple lanes (e.g., a multinational
+agency deployment).
+
+| Jurisdiction | Key Frameworks | Typical Bid Touchpoints |
+|---|---|---|
+| **US federal / state** | FedRAMP (cloud authorization), GovRAMP (formerly StateRAMP, rebrand announced February 2025), FISMA (agency ISMS), NIST SP 800-53 Rev. 5, CMMC 2.0 (defense supply chain) | FedRAMP authorization impact level (Low/Moderate/High) cited in §Technical Approach; FISMA system categorization drives security controls count; CMMC level for any DoD-adjacent work; state procurement code compliance |
+| **EU / EEA** | eIDAS 2 (electronic identity and trust services, including European Digital Identity Wallet provisions), GDPR (personal data), NIS2 (network and information security), EU Cloud Code of Conduct, EUCS (EU Cloud Services scheme, evolving) | Trust-service qualification level for identity components; GDPR Article 28 data-processor clauses; NIS2 incident-reporting SLAs (early-warning within 24h, full notification within 72h); EU-based data processing for public authorities |
+| **Brazil** | LGPD (Lei 13.709 — personal data protection), Lei das Estatais 13.303 (state-owned enterprise procurement rules), Lei 14.133 (Nova Lei de Licitações e Contratos — replaces 8.666 over the 2024-2026 transition), current ICT procurement instruction (verify the operative IN at intake — instructions are revised periodically; previous IN-04/SLTI superseded by subsequent instructions under SGD/ME), ABNT NBR ISO/IEC 27001 | LGPD lawful-basis for data processing; Lei 13.303 competitive-bidding thresholds; current ICT instruction technical qualification requirements; TCU audit readiness |
+| **China / APAC** | 等保2.0 (Cybersecurity Classified Protection Level 2/3/4), 国密 / Guomi algorithms (SM2/SM3/SM4), 数据本地化 (data localization), PIPL (Personal Information Protection Law) | 等保 level classification and remediation plan; Guomi algorithm coverage for identity, transmission, storage; data localization boundary for government-grade deployments; PIPL cross-border transfer controls |
+
+Jurisdiction-neutral minimum bar (applies to all four lanes):
+- Data classification scheme documented before solution design is finalized.
+- Encryption-at-rest and encryption-in-transit with named algorithm + key management plan.
+- Identity and access management design with named authentication assurance level.
+- Audit log retention period and tamper-evidence mechanism specified.
+- Incident response SLA named in the bid.
+
+## Policy Interpretation Discipline
+
+### Reading a policy document for technical implication
+
+1. **Identify the enforcement class.** Distinguish "shall" (mandatory),
+   "should" (recommended), and "may" (permitted) language. Only "shall"
+   clauses are hard controls in the compliance matrix.
+2. **Extract the technical operand.** For each mandatory clause, identify
+   what system component, data type, or process is being constrained.
+   Map each clause to a named architecture element before writing bid prose.
+3. **Trace to an accepted standard.** Cite the specific version of the
+   policy document (publication date, section number, clause number).
+   Paraphrase for readability, but the verbatim clause reference must appear
+   in footnotes or the compliance matrix. Evaluators cross-check.
+4. **Identify the verification artifact.** Each mandatory control must have
+   a named verification artifact: a penetration test report, a third-party
+   assessment letter, a certification document, or a test result. "We comply"
+   without a named artifact is not compliance.
+5. **Date-stamp the policy version.** Regulations are amended. A bid
+   submitted against a superseded policy version is a liability. Record the
+   specific document version cited in every compliance matrix row.
+
+### What bid responses MUST cite verbatim vs. paraphrase
+
+| Item | Treatment |
+|---|---|
+| Mandatory control clause | Verbatim quote in compliance matrix; source, section, and clause number in footnote |
+| Authorization level or categorization | Verbatim label (e.g., "FedRAMP Moderate", "等保 Level 3") — never paraphrase |
+| Applicable law citation | Full statutory reference (e.g., "5 USC §552a" not "the Privacy Act") |
+| Certification or qualification name | Exact name and issuing body; never abbreviate without defining |
+| Performance SLA in contract template | Verbatim from the procuring agency's template — no substitutions without written approval |
+
+## Solution Architecture for Government
+
+### Deployment model selection
+
+| Model | Applicable when | Key constraints |
+|---|---|---|
+| Sovereign / government cloud | Agency policy requires FedRAMP-authorized or equivalently certified IaaS; data must not leave jurisdiction | Named CSP authorization status must be confirmed before architecture is locked; key management must be agency-controlled (BYOK or HYOK) |
+| On-premises government data center | Agency prohibits cloud hosting; classified system boundary required; air-gap mandate | Vendor access to production environment is restricted; deployment procedures must be agency-executable; hardware refresh cycle owned by agency |
+| Hybrid (agency DC + authorized cloud) | Sensitive workloads on-prem; analytics / citizen-facing layers in authorized cloud | Data-residency boundary between tiers must be documented; latency SLA for cross-tier calls must be bid-committed |
+| Commercial cloud (non-sovereign) | Low-sensitivity public-facing services only; no PII at rest; jurisdiction explicitly permits | Confirm agency authority to use non-authorized cloud; document out-of-scope data types; include data-egress controls |
+
+### Cryptography mandates by jurisdiction
+
+| Jurisdiction | Algorithm requirement | Certificate / CA requirement |
+|---|---|---|
+| US federal | FIPS 140-2/3 validated modules; NIST-approved algorithms (AES-256, SHA-2, RSA-2048+, P-256+) | PIV/CAC or FICAM-approved credential for identity |
+| EU | ENISA-recommended; eIDAS qualified certificates for trust services; GDPR-compliant key management | Qualified Trust Service Provider (QTSP) certificate for legal electronic signatures |
+| Brazil | ABNT NBR ISO/IEC 27001; ICP-Brasil certificate chain for legal signatures (MP 2.200-2) | ICP-Brasil Autoridade Certificadora for qualified signatures |
+| China / APAC | SM2 (asymmetric), SM3 (hash), SM4 (symmetric) for government-grade; domestic CA certificate | Approved commercial CA using Guomi certificate profile |
+
+### Data-residency matrix
+
+For each data category in the solution, document:
+- **Storage jurisdiction**: the physical or logical boundary where data at
+  rest resides.
+- **Processing jurisdiction**: where compute operations occur (including
+  analytics, AI inference, log aggregation).
+- **Transit path**: whether data crosses jurisdictional boundaries in transit
+  and under what encryption and legal basis.
+- **Backup / DR jurisdiction**: disaster-recovery replicas may trigger
+  secondary data-residency obligations; confirm these separately.
+
+## Bid Document Structure
+
+A government bid response must contain the following sections in the
+order the RFP evaluation criteria demand. Where the RFP specifies a
+different structure, follow the RFP exactly — evaluators are often
+required to score section-by-section and will penalize out-of-order
+content.
+
+| Section | Required fields | Hard rules |
+|---|---|---|
+| **Executive Summary** | Value proposition; compliance posture summary; key differentiators; management approach overview | ≤ the page limit specified in the RFP; no pricing in this section unless RFP requires it |
+| **Technical Approach** | Architecture overview; deployment model; security architecture; integration plan; Xinchuang / FedRAMP / eIDAS qualification level as applicable; staffing plan; implementation schedule with milestones | Every claim must be traceable to a named product, certified service, or peer-reviewed method |
+| **Compliance Matrix** | One row per RFP requirement (identified by section and clause number); response: "Compliant", "Partially Compliant" (with gap plan), or "Not Compliant" (with rationale); evidence reference | Must be line-by-line traceable to RFP requirements; "Compliant" without an evidence column is insufficient |
+| **Past Performance** | Client name (or anonymized placeholder if confidentiality required); contract value range; scope description; period of performance; client POC name and contact (or attestation it is available upon request); relevance statement | No fabricated references; references must be reachable and willing; relevance must match the scope of the current bid |
+| **Pricing** | Line-item cost breakdown; total evaluated price; payment schedule tied to milestones; warranty / maintenance costs | Pricing must be consistent with Bill of Materials in Technical Approach; no shadow pricing reserved for negotiation |
+| **Risk Register** | Risk description; probability; impact; mitigation; residual risk; owner | At least 5 risks; risks that emerge during delivery and were foreseeable but absent from the bid register are a contractual liability |
+
+### Compliance matrix authorship rule
+
+The compliance matrix is the single most audited section of a government
+bid. Every row must state:
+1. The RFP requirement identifier (section + clause number).
+2. The verbatim or condensed requirement text.
+3. The response disposition: Compliant / Partially Compliant / Not Compliant.
+4. The named evidence artifact: product certification, test report, policy
+   document, or architecture diagram section.
+5. The responsible party (prime contractor or named subcontractor).
+
+A compliance matrix that copies the prior bid's rows without re-verifying
+against the current RFP is a disqualification risk. RFPs change between
+editions. Verify every row against the current document version.
+
+## POC Validation Discipline
+
+### Before POC start
+
+The following must be agreed in writing before any POC environment is
+stood up:
+
+1. **Acceptance criteria**: specific, measurable, falsifiable pass/fail
+   criteria for each POC scenario. "System works well" is not a criterion.
+   "OCR extraction accuracy ≥ 95% on the provided 200-document test set,
+   measured by the agency evaluator" is a criterion.
+2. **Scope boundary**: the POC validates named capabilities, not a full
+   system. Any agency request to add scope during POC requires written
+   change authorization. Undocumented scope expansion is a free project.
+3. **Data protocol**: test data must be agency-provided or
+   agency-approved synthetic data. Vendor-sourced demo data that "looks
+   like" agency data does not satisfy evaluation requirements.
+4. **Evaluation method**: who measures, what tool, what sample size, what
+   time window. If the agency retains the right to re-run tests, define
+   the re-run protocol.
+5. **Sign-off authority**: the individual with authority to sign the POC
+   acceptance report must be identified before the POC starts. Evaluator
+   turnover mid-POC without sign-off transfer is a risk to manage.
+
+### Falsifiability requirement
+
+Every acceptance criterion must have a binary outcome. If the evaluator
+cannot state "this criterion passed" or "this criterion failed" without
+judgment, the criterion is not falsifiable and must be rewritten. Vague
+criteria favor the agency in disputes.
+
+### Sign-off protocol
+
+A POC without a signed acceptance report is an incomplete POC regardless
+of informal feedback. Obtain written sign-off before demobilizing the POC
+environment. Retain the signed report as contract evidence.
+
+## Public Records / Transparency Considerations
+
+Bid documents submitted to government agencies are generally subject to
+public-records disclosure (FOIA in the US, equivalents in other
+jurisdictions) after award. This is not optional and not negotiable. The
+bid document is a semi-public artifact.
+
+### What must NEVER appear in a bid document
+
+- Unpublished proprietary pricing models or margin structures beyond the
+  line-item prices required by the RFP.
+- Non-public client names when a reference is provided under NDA — use
+  "a large municipal agency" and provide the POC contact through a separate
+  confidential channel.
+- Internal personnel salary data; use labor-category rates.
+- Trade-secret technical details beyond what is needed to demonstrate
+  compliance; mark the minimum necessary set as trade secret under the
+  applicable exemption (e.g., FOIA (b)(4)) and confirm the agency will
+  honor the request.
+- Any language implying coordination with another bidder on pricing or
+  technical approach.
+
+Cross-link: `domains/government/skills/foia-and-records` covers the
+exemption framework and redaction mechanics that govern post-award
+disclosure of bid documents.
+
+## Pricing Disclosure Hard-Rules
+
+- **No shadow pricing.** The price submitted is the price to be executed.
+  Reserving a lower price "for negotiation after selection" is an integrity
+  violation in most government procurement frameworks.
+- **No price changes after technical lock.** In multi-envelope procurement
+  (technical envelope scored before commercial envelope opened), modifying
+  the commercial envelope after technical submission is prohibited and may
+  constitute bid fraud.
+- **Cost floor discipline.** A below-cost price that relies on anticipated
+  change orders to recover margin is not a compliant bid; it is a loss-leader
+  that creates delivery and legal risk. Document the cost floor before
+  pricing is finalized.
+- **Consistency between technical and commercial.** The Bill of Materials
+  in the technical proposal and the line-item pricing must reference the
+  same products, quantities, and service levels. Evaluators check for
+  inconsistencies as a signal of poor planning or intentional misdirection.
+- **Warranty and maintenance costs.** Total evaluated price in most
+  government RFPs includes lifecycle costs. Omitting or underestimating
+  O&M costs to win on initial price creates a performance baseline that
+  cannot be sustained.
+
+## Anti-patterns
+
+| Anti-pattern | Description | Consequence |
+|---|---|---|
+| **Over-promising on compliance** | Marking controls "Compliant" in the compliance matrix without confirmed evidence, assuming the gap will be closed during delivery | Audit finding, cure-notice, contract termination; in regulated jurisdictions may constitute a false claim |
+| **"We've done this before" without a case study** | Asserting past performance relevance without a specific, verifiable reference that matches scope, scale, and jurisdiction | Evaluator cannot award performance points; if reference is later found unverifiable, bid may be disqualified retroactively |
+| **Single-jurisdiction generalization** | Applying one jurisdiction's compliance frame (e.g., FedRAMP) as if it satisfies another (e.g., 等保2.0 or LGPD) | Compliance matrix gaps discovered during evaluation or post-award audit; redesign cost falls on contractor |
+| **Copy-paste compliance matrix** | Reusing compliance matrix rows from a prior bid without re-verifying against the current RFP version | Requirements that changed between RFP editions appear incorrectly answered; evaluators flag as inattentive or non-compliant |
+| **Ghosted past-performance citations** | Listing a project reference whose client POC no longer works at the agency or has refused to be listed | Past-performance verification fails; points are zeroed; if the reference was known unavailable, it may be treated as misrepresentation |
+| **POC scope creep acceptance** | Agreeing verbally to add POC scenarios during evaluation without written change authorization | POC exceeds budget; acceptance criteria become ambiguous; agency gains leverage to claim the original criteria were not met |
+| **Loss-leader pricing with change-order recovery intent** | Pricing below cost under the assumption that change orders will make the contract profitable | Government contracting officers are trained to detect this; protests from competitors; unsustainable delivery; reputational damage |
+| **Bid document as sales brochure** | Filling bid narrative with marketing language and vendor-capability descriptions not directly responsive to RFP requirements | Evaluators score for responsiveness; non-responsive sections earn zero points regardless of quality |
+
+## Cross-References
+
+- `domains/government/skills/foia-and-records` — FOIA exemption framework,
+  redaction mechanics, and post-award bid-document disclosure obligations.
+- `domains/government/skills/public-procurement` — Bid-confidentiality
+  invariants, debarment-list vetting, COI declarations, and protest-survivability
+  requirements for the procurement lifecycle.
+- `domains/government/skills/accessibility-section-508` — Section 508 / WCAG
+  compliance requirements for digital government deliverables; a mandatory
+  compliance matrix row in US federal and many state bids.
+- `core/compliance-lgpd` — LGPD data-processing rules, lawful-basis mapping,
+  and data-subject rights mechanics for Brazilian public-sector engagements.
+
+## ADR Anchors
+
+- **ADR-058** — Two-pass review discipline for high-stakes authored artifacts.
+  Bid documents are explicitly in scope: a technical proposal and its compliance
+  matrix must pass a two-pass review (first pass: technical accuracy and
+  completeness; second pass: compliance matrix row-by-row verification against
+  the RFP) before submission. A single-pass review is insufficient for
+  government bid documents.

package/.claude/skills/domains/government/skills/foia-and-records/SKILL.md

@@ -0,0 +1,211 @@
+---
+name: foia-and-records
+description: FOIA (5 USC §552) compliance engineering — records lifecycle, retention schedules, redaction audit trails, and request fulfillment. State equivalents (state sunshine laws, public records acts) follow the same pattern with tighter SLAs. Covers retention classification, tombstoning vs hard delete, exemption-based redaction with legal basis, requester-identity confidentiality, SLA clock machinery, and the "default open" posture for public records. Use when designing any records-producing subsystem, any retention policy, any redaction tool, or any FOIA request-intake workflow.
+owner: Yewande Crossland (FOIA Compliance Officer, domain persona)
+secondary_owner: Darius Okonkwo (Public Records Engineer, domain persona)
+tier: domain:government
+scope_tags: [foia, public-records, retention, redaction, transparency, records-management]
+# --- smart-loading fields (PLAN-083 Wave 0b sub-agent 0.7c) ---
+domain: government
+priority: 8
+risk_class: medium
+stack: []
+context_budget_tokens: 700
+inactive_but_retained: true
+repo_profile_binding:
+  frontend: {active: false, priority: 10}
+  engine: {active: false, priority: 10}
+  fintech: {active: false, priority: 10}
+  trading-readonly: {active: false, priority: 10}
+  generic: {active: false, priority: 10}
+activation_triggers: []
+# --- K1 paths: native file-touch activation (PLAN-135 W3 unit k1a) ---
+paths:
+  - "**/records/**"
+  - "**/retention/**"
+  - "**/redaction/**"
+  - "**/foia/**"
+---
+
+# FOIA & Public Records
+
+## Cardinal Rule
+
+**Public records are default-open; the burden of withholding is on
+the agency, per record, per exemption.** Software that treats records
+as private-by-default and opens them on request is inverted.
+Software that treats records as public-by-default and redacts with
+logged legal basis is correct.
+
+## The nine FOIA exemptions (5 USC §552(b))
+
+| # | Exemption | Typical applicability |
+|---|---|---|
+| (b)(1) | National security (classified) | Defense/intel |
+| (b)(2) | Internal agency rules/practices (Low 2 + High 2) | Rare for most agencies |
+| (b)(3) | Specifically exempted by other statute | Narrow; cite the statute |
+| (b)(4) | Trade secrets / confidential commercial | Vendor submissions, contract bids |
+| (b)(5) | Deliberative process / attorney-client / attorney work product | Internal drafts, legal memos |
+| (b)(6) | Personal privacy (unwarranted invasion) | Personnel, medical, benefits |
+| (b)(7) | Law enforcement records (A-F sub-categories) | Investigations |
+| (b)(8) | Financial institutions examination | Bank regulators |
+| (b)(9) | Geological/geophysical (oil wells) | Niche |
+
+For most agency software the hot exemptions are **(b)(4)**, **(b)(5)**,
+**(b)(6)**, and occasionally **(b)(7)**. Every redaction MUST be
+labeled with its exemption number + brief legal basis note.
+
+## Records lifecycle (the machinery)
+
+```
+created -> classified -> active -> retention-elapsed -> disposition
+                                                              |
+                           +----------------------------------+
+                           |                                  |
+                           v                                  v
+                        destroyed                         transferred
+                      (tombstoned,                       (to NARA or
+                     not hard-deleted                    state archive)
+                      if a FOIA request
+                      is pending)
+```
+
+### Hard invariants
+
+1. **Every record has a retention classification** set at creation
+   time. "We'll classify it later" = permanent classification of
+   "unknown" = audit finding. Use the agency's records schedule
+   (NARA GRS or agency-specific).
+2. **Retention clock starts from the correct event.** "Date of
+   last action" vs "date of closure" vs "date of creation" matters.
+   Classify by event type, not by record age alone.
+3. **"Deleted" MUST mean tombstoned + audit-logged.** A hard DELETE
+   that loses the existence record breaks FOIA accountability. The
+   tombstone records: record_id, creation_date, destruction_date,
+   retention_schedule_cited, authorized_by, destruction_method.
+4. **If a FOIA request is pending on the record, destruction is
+   frozen** regardless of retention schedule. Call this the "FOIA
+   litigation hold". Automated purge pipelines MUST consult the
+   hold list before deleting.
+5. **Email and chat are records.** Agency employees generating
+   correspondence about official business are creating records.
+   Pretending otherwise does not survive discovery.
+
+## Redaction — the thing that actually trips software up
+
+### Wrong way (every agency has done this once)
+
+- Black rectangle overlaid on PDF — underlying text still selectable,
+  copyable, and searchable. Redaction is cosmetic.
+- CSS `display: none` on sensitive fields in HTML — View Source reveals all.
+- Image downscaled "enough" to be unreadable — super-resolution ML
+  recovers it.
+
+### Correct way
+
+- **True pixel redaction** on images/PDFs: re-rasterize after
+  applying an opaque mask; drop the original text layer; strip
+  EXIF and document metadata.
+- **Text redaction**: replace with `[REDACTED (b)(6) — personal privacy]`
+  at the data layer, not just the rendering layer. The redacted value
+  is NOT retrievable via the API for audiences who should not see it.
+- **Audit trail per redaction**: record_id, field_id (or bbox for
+  image), exemption_applied, legal_basis_note, redacted_by,
+  redacted_at, reviewed_by. Auditor can reconstruct every decision.
+- **Dual-layer storage**: unredacted + redacted are both first-class
+  records. Access control determines which version a requester
+  sees. NEVER overwrite the unredacted; destruction follows its
+  own schedule.
+
+## Requester identity confidentiality
+
+- **The requester's identity is their own private matter.** In most
+  cases the subject of a record has NO right to know who asked for
+  it. Software that notifies "John, Jane just requested your file"
+  is a privacy breach dressed as a feature.
+- Exceptions exist (e.g. Privacy Act access to your own file reveals
+  who you are to yourself, trivially). But the default is
+  requester-identity is not disclosed to record subjects.
+- This propagates to logs, analytics, and webhooks. A FOIA request's
+  submitter email does NOT belong in the record's audit trail except
+  in a restricted-access field.
+
+## SLA clock mechanics
+
+- **Federal FOIA baseline**: 20 working days to determine (not to
+  deliver). Extended 10 working days for "unusual circumstances".
+- **State sunshine laws**: usually 3-10 business days, varying
+  heavily. Some states have hard hour limits (e.g. Texas: "prompt").
+- **Clock starts on receipt of a perfected request** (specific
+  enough records + requester contact + fee commitment if applicable).
+  An underspecified request does NOT start the clock — engineering
+  MUST surface whether the request is perfected.
+- **Clock tolled** by: fee disputes, requester clarification requests,
+  litigation hold under other law. Tolling events MUST be logged with
+  start/end timestamps.
+
+## Schema sketch
+
+```sql
+CREATE TABLE records (
+    id UUID PRIMARY KEY,
+    created_at TIMESTAMPTZ NOT NULL,
+    record_type TEXT NOT NULL,
+    retention_schedule_id UUID REFERENCES retention_schedules(id),
+    retention_start_event TEXT NOT NULL,  -- e.g. 'closure', 'creation'
+    retention_start_at TIMESTAMPTZ NOT NULL,
+    public_posture TEXT NOT NULL CHECK (public_posture IN
+        ('public', 'foia-reviewable', 'classified', 'exempt-pending-review')),
+    tombstoned_at TIMESTAMPTZ,  -- NULL while active
+    tombstone_reason TEXT,
+    tombstone_authorized_by UUID,
+    foia_hold BOOLEAN NOT NULL DEFAULT FALSE
+);
+
+CREATE TABLE redactions (
+    id UUID PRIMARY KEY,
+    record_id UUID REFERENCES records(id),
+    field_or_bbox TEXT NOT NULL,
+    exemption TEXT NOT NULL,  -- '(b)(6)', '(b)(4)', ...
+    legal_basis TEXT NOT NULL,
+    applied_by UUID NOT NULL,
+    applied_at TIMESTAMPTZ NOT NULL,
+    reviewed_by UUID,
+    reviewed_at TIMESTAMPTZ
+);
+
+CREATE TABLE foia_requests (
+    id UUID PRIMARY KEY,
+    received_at TIMESTAMPTZ NOT NULL,
+    perfected_at TIMESTAMPTZ,  -- NULL until clarified
+    requester_identity_hash TEXT NOT NULL,  -- restricted lookup
+    scope_description TEXT NOT NULL,
+    sla_deadline_at TIMESTAMPTZ,
+    tolled_from TIMESTAMPTZ,
+    tolled_reason TEXT,
+    closed_at TIMESTAMPTZ,
+    closure_disposition TEXT
+);
+```
+
+## Pre-merge checklist (domain VETO trigger)
+
+- [ ] **Retention classification set at record creation?**
+- [ ] **Retention clock anchored to the correct event?**
+- [ ] **"Deleted" path tombstones + audit-logs; no hard DELETE?**
+- [ ] **FOIA litigation hold consulted before any purge?**
+- [ ] **Every redaction carries exemption + legal basis + actor?**
+- [ ] **Redaction happens at data layer, not only render layer?**
+- [ ] **Requester identity NOT disclosed to record subject?**
+- [ ] **SLA clock logic handles perfection + tolling correctly?**
+- [ ] **Email/chat retention captured if in scope?**
+- [ ] **Destruction path verifies no pending FOIA touches record?**
+
+## References
+
+- 5 USC §552 (Federal FOIA)
+- 36 CFR Chapter XII (NARA records management)
+- NARA General Records Schedule (GRS)
+- DOJ OIP FOIA guidance (annually updated)
+- `.claude/skills/domains/government/skills/public-procurement/SKILL.md`
+  (vendor-submitted trade secrets — (b)(4) intersection)