IF.GOV Decision Pack (demo) — “Acme Support Copilot” (fictional)

Audience: external reviewers + operators
Reality gate: docs/22-ifttt-handover-and-roadmap.md (single-host; receipts-first)
Not legal advice. This is a governance deliverable template + demo.

This is a demo decision pack for a fictional casefile:

• Input casefile: docs/33-ifgov-decision-pack-demo-input.md

0) Links (HTML-first; one per line)

Decision pack (hosted-static HTML): https://infrafabric.io/static/hosted/review/if-gov-decision-pack-demo/2026-01-05/index.html

IF.TRACE/T3 receipt (shareId): https://infrafabric.io/static/trace/zxWjdzxZd2FiuYpfS90ETFMj

Pack (HTML view): https://infrafabric.io/static/pack/zxWjdzxZd2FiuYpfS90ETFMj

Pack (raw Markdown): https://infrafabric.io/static/pack/zxWjdzxZd2FiuYpfS90ETFMj.md

1) What this pack proves (black/white)

Proves:

• The published bytes of this decision pack match the hashes on the IF.TRACE receipt.
• The input casefile bytes (if published) match the hashes on the IF.TRACE receipt.
• Where signatures exist and keys are discoverable, signatures can be verified.

Does not prove:

• That any narrative statement here is true.
• That Acme will comply with anything.
• That the system is safe, secure, or deployed.

“QUANTUM READY” means: a post‑quantum signature receipt exists for this trace (verification may require PQ tooling). It is not “quantum-secure”.

2) Executive summary (decision)

Decision: Approve with conditions (demo).

Why:

• Drafting + summarization can reduce support load if humans remain the final decision-maker.
• The main failure modes are governance failures (scope creep, weak review gating, poor evaluation), not “model choice”.

Conditions (must be true before rollout):

1. Human review is enforced in UI and logs (no auto-send).
2. A small evaluation set exists with clear pass/fail criteria.
3. A “bad draft shipped” incident procedure exists (stop button + escalation).
4. Data-handling mode is chosen explicitly (see §6).

3) Scope and non-goals

In-scope:

• draft reply suggestions
• internal summaries for support agents
• ticket triage suggestions (human-confirmed)

Out-of-scope:

• autonomous replies
• access to payment systems or production databases
• “compliance certification” claims

4) Risk register (top risks)

Risk 1 — Hallucinated commitments (refunds / SLAs / policy promises)

• Likelihood: medium
• Impact: high
• Mitigation: “draft-only” UI, mandatory human review, forbidden-claim linting in templates, audit sampling.

Risk 2 — Sensitive data disclosure (PII, internal incident notes)

• Likelihood: medium
• Impact: high
• Mitigation: redact/guardrails at intake; no-retention preferred; logging discipline; role separation.

Risk 3 — Scope creep (draft-only becomes “auto-send”)

• Likelihood: high
• Impact: high
• Mitigation: hard policy gate; require IF.GOV re-review for any automation step-change.

Risk 4 — Evaluation theater (no real pass/fail)

• Likelihood: high
• Impact: medium
• Mitigation: publish evaluation plan and require evidence artifacts; bind outputs to receipts.

Risk 5 — Incident response gap (“bad draft shipped” has no owner)

• Likelihood: medium
• Impact: high
• Mitigation: explicit owner + playbook + stop conditions + logging for audit.

5) Control plan (gates and stop conditions)

Gate A — Draft-only enforcement

• Required: the system cannot send without a human confirmation action.
• Evidence: UI screenshots are not sufficient; require an auditable event log and a spot-check procedure.

Gate B — Forbidden claim linting

• Required: detect and block drafts that include forbidden commitments (“refund approved”, “SLA guaranteed”) unless a human overrides with justification.
• Evidence: show the rule list and override logs.

Gate C — Evaluation pass/fail

• Required: the evaluation set is defined and results are recorded.
• Evidence: evaluation report + raw inputs/outputs (as permitted) + receipt links.

Stop condition 1 — Repeat critical failure

• Trigger: ≥2 critical incidents in a rolling 7-day window (e.g., leaked incident details, hallucinated refund promise shipped).
• Action: disable copilot for external-facing replies until IF.GOV re-review.

Stop condition 2 — Data-handling breach

• Trigger: evidence of retention beyond the selected mode (see §6).
• Action: stop + investigate + publish a delta pack if the decision changes.

6) Data-handling mode (choose explicitly)

Mode 1 — No retention (hash-only):

• Store only hashes + receipt metadata.

Mode 2 — Retention window:

• Store inputs/outputs for a fixed time window (e.g., 7/30/90 days).

Mode 3 — Client-hosted export-only:

• Client holds the bundles; we keep only hashes.

This demo does not choose a mode; a real pack must.

7) Evaluation plan (minimum viable)

Define:

• ticket categories in scope (start with a narrow subset)
• “known bad outcomes” list (refund promises, policy misquotes, sensitive disclosure)
• pass/fail criteria per category

Minimum tests:

1. Draft quality: human rating rubric (clarity, correctness, tone).
2. Safety: forbidden-claims detection rate (and override rate).
3. Privacy: redaction effectiveness (no secrets/PII beyond what the agent already sees).
4. Reliability: degraded mode behavior (copilot down → manual workflow still works).

Outputs to publish (demo/real):

• evaluation report
• receipts that bind evaluation artifacts (hash-only if needed)

8) Assumptions + what would change our mind

Assumptions:

• Human review is enforced, not optional.
• Rollout is scoped and staged.

Would change our mind:

• If the business demands autonomous sending without compensating controls.
• If evaluation cannot be made auditable.
• If data-handling requirements cannot be satisfied on the current single-host deployment.

9) Receipt block (fill in per pack)

Receipt surface (one per line): https://infrafabric.io/static/trace/zxWjdzxZd2FiuYpfS90ETFMj https://infrafabric.io/static/pack/zxWjdzxZd2FiuYpfS90ETFMj