Vertical demo assets — AML case and credit operation

Two entirely fictitious dossiers that complete the Aurora dossier's story. The demo principle is explicit: one fictitious client, three moments, one platform — the worst possible demo shows three disconnected products.

Every document carries the fictitious-data notice in its header. At a booth or in a presentation, say out loud that the data is fictitious.

The story, in three moments

The continuity is not rhetorical: the CNPJs and CPFs are the same across the three fixtures, and make fixtures-demo-check fails if they diverge. The beneficial owner KYB found hidden four levels down — Ricardo Andrade Meira — is the same person who controls the company investigated in the AML case.

AML/CFT case — CASO-2026-0417

Investigated: Cassiopeia Administração e Participações. Twelve documents: case opening, alert record, registration file, statement for the period, correspondence with the client, ownership and watchlist lookups, and the preliminary analysis.

The last one matters most in the demo, and is the only one whose correct outcome is not an anomaly. A namesake without documentary confirmation must come out as pending, with the caveat stated in the report. That is what separates an auditable investigation layer from an accusation generator — and it is the ready answer to the "what if the AI hallucinates?" objection.

Credit operation — EMP-2026-0912

Borrower: Aurora Logística. The data context is Emprestimos, which already existed and was reused rather than duplicated — which is why the dossier key is EMP-2026-0912, in that context's numeroPedido anchor format. A key in any other format would land without an anchor and the dossier would not be findable from the screen. The credit criteria live in Emprestimos itself (both data and rule context), with regrasContextos: ["Emprestimos"] — the same self-reference pattern as PLD. Measured in production on 2026-08-22: a separate rule context would have to exist as a context, and creating a CreditoDocumental just for that is the opposite of reusing Emprestimos.

Ten documents: internal approval, bank credit note, signatory power of attorney, annex of the pledged fleet, registration receipts, insurance policy, financial statements and the formalization checklist.

The term divergence is this act's climax. Formalizing terms different from those approved is the finding internal audit looks for, and it is invisible to anyone reading only the instrument — it surfaces only with both documents side by side, which is precisely the product's evidence screen.

The power of attorney is a deliberate measurement trap: it is valid on the analysis date and expired on the date the instrument was signed. Anyone checking "valid today" passes it; the criterion requires validity on the signature date.

How to load

The versioned fixture is the generator, not the files: dates are relative to the load day, so that "alert 12 days ago" is true on demo day.

DATTA_API_URL=http://<gateway>:7070 DATTA_JWT=<accessToken> \
  ./scripts/seed-demo-vertical.sh pld

DATTA_API_URL=http://<gateway>:7070 DATTA_JWT=<accessToken> \
  ./scripts/seed-demo-vertical.sh credito

Prerequisites, and the seed does not create them:

• For pld: a context named InvestigacaoPLD, of type AML/CFT Investigation, with regrasContextos: ["InvestigacaoPLD"].
• For credito: the existing Emprestimos context, with regrasContextos: ["Emprestimos"] added (self-reference).
• For both: the corresponding BPMN model published.

Registering a context requires CONFIG_EDIT — it is an admin act, and a service token is refused by design. A context without regrasContextos has an empty rule corpus: there is no default by type, and triage would find no criteria at all. The seed also seeds the context prompts — without them NER falls back to the default legal prompt and the case graph is never born.

Reloading requires purging

Same trap as the Aurora dossier: the document identifier is the content hash, and the content changes every day. Re-running on another day accumulates a second dossier instead of replacing the first, and triage starts reading both versions together. To truly replace, use PURGAR=1.

The anchor comes from NER, not from the batch target

The upload screen's batch opening accepts a target CNPJ and nothing else — it anchors the whole batch to a company, which suits the registration dossier. Here the anchor is different: the case, in the investigation; and the one declared in the context registration, in credit. So the seed states no target: the anchor entity is born from entity recognition over the documents themselves, and each vertical's prompts declare it as the first extracted type. Generalizing the batch target to any (label, property) pair is recorded as a pending item in the backlog.

The gate

make fixtures-demo-check

It checks that every finding promised in the generator's docstring actually exists in the generated text, with a fixed base date. A fixture has its own silent failure mode: the docstring promises "power of attorney expired on the signature date", someone edits a date thinking it was a typo, and the document becomes consistent. Nothing breaks — not the build, not a test. The defect only shows up at the booth, with the criterion green and the presenter with nothing to show.