Draft breach notices and deadlines

# Assemble the Decosa incident notification pack on this machine

You are setting up a drafting and checking aid for a CISO and general counsel during a cyber incident. From the team's
incident log (time with a zone, source, text, tags), the entity fields, the regimes counsel is considering and the
notices to draft or check, it seals the log as a hash-chained timeline, computes each report's deadline clock in code
from the tagged entries (SEC 8-K Item 1.05, EU NIS2 Art. 23, EU DORA, EU Cyber Resilience Act Art. 14, California Civ.
Code 1798.82), drafts or checks each notice sentence by sentence against the entries it cites, lists the required
elements a notice lacks and the facts two notices state differently, and returns a Markdown pack and a JSON report
signed by this box's own key. Counsel signs off with a second signed record. Work step by step, show me each command
before you run anything with `sudo`, and stop to ask if a check fails.

## Step 0: set up with a coding agent, rehearse on mock data, then go private

This prompt is for a coding agent running on the machine that will host the service. We recommend Claude Code with
Claude Opus 5.5; any capable coding agent works. Work in this order:

1. Set up on mock data only. During the whole setup you (the agent) work with the synthetic sample bundle below and
   nothing else. Do not ask me for real data, and do not open, read, list or copy files that hold real data, even to
   "test with something realistic".
2. Rehearse. When the steps below are done and the service is healthy, fetch the mock-data bundle for this tool,
   https://decosa.ai/samples/incident-notification-pack.zip (5 KB, 13 checks, synthetic or openly licensed: see `licence` in expected.json),
   show me what is in it, and run the rehearsal against the local API:
   `docker compose exec api python scripts/rehearse.py incident-notification-pack` (the api image carries the same bundle under /app/rehearsal/incident-notification-pack/;
   with no key set, the script asks the local API for a short demo token). From a decosa-api checkout instead:
   `python scripts/rehearse.py incident-notification-pack --bundle incident-notification-pack.zip --base-url http://127.0.0.1:<PORT>`.
   It sends the mock inputs to the local API and prints PASS or FAIL for each expected property (for example: "the pack needs attention", "the wrong detection time is held as a time mismatch", "the held time names the logged one"). Show me
   the full output. Every check must pass. If one fails, fix the install and run it again; never edit `expected.json`
   to make a check pass.
3. Stop there. Once the rehearsal passes, tell me, and I will run my own data against the local API myself, on this
   machine.

For the person running this: a coding agent that runs in the cloud sees everything in its context, including files it
reads, command output and anything pasted into the chat. Keep real data out of the chat and out of anything the agent
can read. Switch to your own data only after the rehearsal has passed and the agent's work is done.

## 0. Ground rules and licences
- Model: Qwen3.8-27B (Apache-2.0), used for three jobs: drafting a notice with citations when none is given, the
  grounding judge (is the sentence backed by the entries it cites), and one element review per notice. The clocks, the
  time and number checks, the contradictions, the timeline record and the report are decosa-api (AGPL-3.0-or-later) and need
  no GPU of their own.
- Incident facts are privileged work product and may be material non-public information. The log stays on this
  machine. Bind every port to 127.0.0.1. The service keeps no log or notice text: logs carry counts only. Keep it that
  way; do not add request logging.
- Be honest about what it is: a drafting and checking aid, not legal advice and not a filing. Counsel decides whether a
  regime applies, whether the incident is significant, major, material or severe, what to file and when, and files it.
  Clocks are only as right as the tags on the log entries.

## 1. Check the machine
1. `nvidia-smi`: one GPU with at least 32 GB (Qwen3.8-27B NVFP4 needs about 20 GB of weights plus KV cache; an RTX PRO
   6000 96 GB is what we measured on; an RTX 5090 32 GB should fit but we have not run this tool on one). Driver
   570 or newer. Blackwell cards run NVFP4; on older cards use `Qwen/Qwen3.8-27B-FP8`.
2. `docker --version` and `docker compose version`. If Docker or the NVIDIA container toolkit is missing, install them
   from the official Docker and NVIDIA repositories after asking me, then run
   `docker run --rm --gpus all nvidia/cuda:12.8.0-base-ubuntu24.04 nvidia-smi`.
3. Disk: about 30 GB free.

## 2. Images and weights
- `${DECOSA_REGISTRY}/decosa-api:<tag>` (**publishing soon**). If the pull fails, build from source:
  `git clone <decosa-api source: on request at https://decosa.ai/contact?topic=self-host>` (access required), check out the newest release tag that
  contains `decosa_api/verticals/incident/` (`main` until one does), and build `docker/api/Dockerfile`.
- `vllm/vllm-openai:v0.29.0` for the model; weights `nvidia/Qwen3.8-27B-NVFP4` (revision
  `482ca0f3832238542f8f5295dde86b5f22711d80`), or `Qwen/Qwen3.8-27B-FP8` on a card without NVFP4.

## 3. docker-compose.yml
Write this in `~/decosa/incident/`:

```yaml
services:
  llm:
    image: vllm/vllm-openai:v0.29.0
    command: ["--model", "nvidia/Qwen3.8-27B-NVFP4", "--served-model-name", "qwen3.8-27b", "--max-model-len", "32768",
              "--enable-prefix-caching"]
    ports: ["127.0.0.1:8114:8000"]
    volumes: ["~/.cache/huggingface:/root/.cache/huggingface"]
    deploy: { resources: { reservations: { devices: [{ driver: nvidia, count: 1, capabilities: [gpu] }] } } }
    healthcheck: { test: ["CMD", "curl", "-fs", "http://localhost:8000/v1/models"], interval: 30s, retries: 20 }
  api:
    image: ${DECOSA_REGISTRY}/decosa-api:<tag>
    ports: ["127.0.0.1:8445:8445"]
    environment:
      DECOSA_HOST: 0.0.0.0
      DECOSA_PORT: "8445"
      DECOSA_DATA_DIR: /data
      DECOSA_LLM_ROUTE: direct
      DECOSA_LLM_URL: http://llm:8000/v1
      DECOSA_LLM_MODEL: qwen3.8-27b
      DECOSA_INCIDENT_SYNTHETIC_ONLY: "0"
      # optional: packs run at once, and model calls in flight per pack
      # DECOSA_INCIDENT_MAX_CONCURRENT: "3"
      # DECOSA_INCIDENT_WORKERS: "6"
      DECOSA_BUDGET_LLM_TOKENS: "60000"
    volumes: ["decosa-data:/data"]
    depends_on: { llm: { condition: service_healthy } }
    healthcheck: { test: ["CMD", "python", "-c", "import urllib.request; urllib.request.urlopen('http://localhost:8445/incident/info', timeout=4)"], interval: 30s, retries: 10 }
volumes:
  decosa-data:
```

`DECOSA_INCIDENT_SYNTHETIC_ONLY: "0"` lets this box take real incidents; the hosted service refuses anything not
marked `"synthetic": true`. The api keeps its state (keys, receipts, this box's signing key) in the named volume
`decosa-data`, not in a host folder: the image runs as an unprivileged user (uid 10001), and a host folder that Docker
creates is owned by root, which stops the api with `PermissionError: [Errno 13] Permission denied: '/data/keys.sqlite'`.
Then start everything: `docker compose up -d`.

Prefix caching matters: every sentence check and element review of one pack sends the same log first.

On the first start the api creates this box's Ed25519 key in the `decosa-data` volume (`/data/attest/`, mode 0600).
Back it up with `docker compose cp api:/data/attest ./attest-backup` and keep that copy private. Never print it. Every
model call on the direct route gets a receipt signed with that key (status `attested`): an attestation by me, the
operator, not a proof of computation. Never set `DECOSA_LLM_ROUTE=gateway` on this box: that sends incident data to
the hosted Decosa API.

## 4. Smoke test
1. `curl -s localhost:8445/incident/info | jq '{regimes: (.regimes | keys), limits, synthetic_only}'` shows
   `sec_8k`, `nis2`, `dora`, `cra`, `ca_breach` and `synthetic_only: false`.
2. Token: `T=$(curl -s -XPOST localhost:8445/demo/session -H 'content-type: application/json' -d '{"vertical":"incident-notification-pack"}' | jq -r .token)`.
3. `curl -s localhost:8445/incident/samples > samples.json`, then
   `jq '.[] | select(.id=="ransomware-saas") | {incident, entity, log, regimes, notices, synthetic}' samples.json > ransomware.json`.
4. Clocks alone, no model call:
   `curl -s -XPOST localhost:8445/incident/clock -H "authorization: Bearer $T" -H 'content-type: application/json' -d @ransomware.json | jq '.clocks[] | {title, status, due_local, late_by}'`.
   Expect the NIS2 early warning `late` by 7 h 0 min and the Form 8-K `open`, due 17:30 Eastern on the fourth business
   day after the materiality entry.
5. The pack: `curl -s -XPOST localhost:8445/incident/pack -H "authorization: Bearer $T" -H 'content-type: application/json' -d @ransomware.json > res.json`.
   Expect `status: "needs_attention"`: the 8-K sentence with 04:12 UTC held as `time_mismatch` (the cited entry says
   03:12 UTC), the NIS2 sentence saying no personal data was taken held as `contradicted`, the 8-K `impact` element
   missing, and contradictions between the two notices on detection time, systems affected and whether data was taken.
   Most other sentences are `checked`.
6. `jq '{report, pack_md}' res.json | curl -s -XPOST localhost:8445/incident/verify -H 'content-type: application/json' -d @-`
   must show `valid_signature`, `signed_by_this_server` and `pack_md_matches` true. Change `status` in the report and
   verify again: it must fail. `jq .record res.json | curl -s -XPOST localhost:8445/record/verify -H 'content-type: application/json' -d @-`
   must show `ok: true`.
7. Sign-off: `jq '{report, reviewer: {name: "Test Counsel", role: "General counsel"}, decision: "changes_requested"}' res.json | curl -s -XPOST localhost:8445/incident/signoff -H "authorization: Bearer $T" -H 'content-type: application/json' -d @- > so.json`,
   then verify it with `jq -s '{report: .[0].report, signoff: .[1].signoff}' res.json so.json | curl -s -XPOST localhost:8445/incident/verify -H 'content-type: application/json' -d @-`:
   `signoff.valid_signature` and `signoff.matches_report` true.
8. Stream one with `-H 'accept: text/event-stream' -N`: `ready`, then `notice`, `receipt`, `sentence` and `review`
   events, then `report`, `budget` and `done`.
9. Time it and tell me what you measure. The ransomware sample took about 33 s on our shared RTX PRO 6000 through the
   gateway; the direct route is usually faster.

## 5. Point the app at the local API
Set `NEXT_PUBLIC_DECOSA_API=http://127.0.0.1:8445` in the site's `.env.local`, or call `POST /incident/pack` from your
incident tooling and keep `pack_md`, the signed `report`, the sealed `record` and counsel's sign-off with the incident
file. `POST /incident/clock` returns the clocks alone, with no model call, whenever the log changes. Contract:
`API_CONTRACT.md`, section "Changes (incident-notification-pack, 2026-09-26)".

Off by default. Joining serves other people's requests on this GPU; never do it on a box that holds incident data. If I
ask for it, follow the provider guide at `/provide` on the site, and do not enable it without my explicit yes.