Demo dossier — Aurora Logística (KYC/KYB)

The KYC/KYB vertical's demo asset: an entirely fictitious PJ account-opening dossier with 23 mutually coherent documents and the planted findings that let the demo tell the whole story — from the corporate divergence to the ultimate beneficial owner hidden four levels down.

Every document carries the fictitious-data notice in its header. Companies, people and figures are invented; the CNPJ/CPF check digits are valid only to exercise the platform's validation. At a booth or presentation, say out loud that the data is fictitious.

The story

Aurora Logística e Participações Ltda (CNPJ 12.345.678/0001-95) opens an account. No direct partner exceeds 25%:

But the chain goes on: Ricardo Andrade Meira holds 75% of Vega Investimentos, which gives him 75% × 24% = 18% of Aurora through Andrômeda — plus 65% of Cassiopeia, i.e. another 13% through a second path. Effective total: 31%, through two distinct paths, on the fourth layer of the chain — while the beneficial-owner declaration states nobody reaches 25%. That is the divergence triage must flag and the side-by-side evidence must show.

What is planted

The Delta branch is deliberate and looks like an oversight, so it is worth explaining. It is an 18% shareholder and the dossier carries neither its articles of association nor its CNPJ card — a real dossier often arrives like this. The effect is exactly what the analyst needs to see: there is a stretch of the ownership chain that does not close, and the report says which one. It does not displace the climax — Ricardo's omitted beneficial ownership remains the main finding, and Delta is the second, showing the difference between documents that contradict each other and a document that does not exist. Closing the branch would cost both findings and break the "twenty-three documents" the script says out loud.

How to load

The versioned fixture is the generator (scripts/demo/dossie-aurora/gerar-dossie.py), not the files: certificate dates are relative to the load day, so that "expiring in 11 days" is true on demo day.

# In-cluster (S2S) — the seed generates the 23 documents and sends them
# through the REAL ingestion (batch with target CNPJ → NER → reconciliation →
# cross-link → triage):
CONTEXTO=OnboardingPJ \
DATTA_INTERNAL_TOKEN=<S2S token> \
./scripts/seed-dossie-aurora.sh

Prerequisites: a context of type Registration File (KYC/KYB) and the BPMN models published (onboarding-pj-kyb with auto-start, pendencia-compliance). The seed files already ship datta:contexto as OnboardingPJ, which is the default of seed-dossie-aurora.sh. If the registered context has a different name, adjust the attribute before publishing — with a name that does not exist, the triage phase fails with "context not registered". The seed also seeds the context's KYB prompts (NER, triage and system — without them NER falls back to the default legal prompt and the corporate graph is never born), ensures the 44 KYB criteria (scripts/criterios-kyb-exemplo.json) and registers the demo dossier in the Knowledge Catalog.

The seed writes nothing out-of-band: the entire graph (companies, partners, percentages, certificates, proxies) is born from NER over the documents, as in a real dossier.

Reloading requires purging

The document identifier is the SHA-256 hash of the content, and this fixture's content changes every day — dates are relative to --data-base, by design. Re-running the seed on another day, or after touching the generator, accumulates a second dossier instead of replacing the first, and triage then reads both versions together.

Measured on 2026-08-11: a re-run after fixing the certificates left 43 documents and 45 chunks (they were 23 and 24), and the report kept citing the old — expired — certificates the generator had just fixed.

To actually replace it:

PURGAR=1 ./scripts/seed-dossie-aurora.sh

PURGAR=1 calls the context purge (the same operation as the screen, cascading BPM instances) before loading. Without the variable the script only warns when it finds a previous dossier — it never deletes anything on its own.

Demo script (3 minutes)

1. PJ Onboarding → Aurora's dossier → Criteria tab: the corporate divergence in red, with side-by-side evidence (articles of association × beneficial-owner declaration).
2. Corporate graph tab: the chain draws itself; the path to Ricardo lights up — 31% through two paths, no direct partner above 25%.
3. Compliance Pendencies: certificates and failed criteria in one list; the labour certificate already with its treatment recorded in a BPM process — who decided, when, and why.

The script runs from the console, not from the flow instance: beneficial owner resolution and dossier reading are the console's own queries, independent of whether the BPM process has advanced.

Why no certificate is born expired

Measured on the cluster on 2026-08-11: the model's Gw_Completo gateway requires statusTriagem == 'CONFORME' to move on to the UBO phase. An expired certificate closes criterion KYB-COMP-3 as ANOMALIA, and the flow takes the "Incomplete" branch → Request documents → Documents received → completeness again, never reaching T_Ubo. The report stopped at the 3 completeness criteria instead of 44, and the corporate part — the script's climax — never happened in the flow.

That is why the dossier's certificates expire soon, never in the past: within the alert window (30 days, DIAS_ALERTA_PADRAO) they still show up in the Pendencies Panel, which was their role in the script, without failing completeness.

The gate keeps its current semantics: any completeness anomaly blocks. Distinguishing missing document from document present but expired would require a severity signal the triage does not emit yet — temAnomaliaCritica does not serve, it is derived from a count (anomalias >= 3).

Operating without internet (trade show, booth, isolated environment)

The platform is on-premises by design, but that is not enough to guarantee the demo survives a Wi-Fi outage. The LLM, NER, embedding and rerank providers are per-context settings, not chart settings — and a context created without choosing a provider is born on gemini, which leaves the cluster. That is the right choice in production with a network and the wrong one at the booth.

The failure mode is the worst possible: everything passes in rehearsal, with Wi-Fi, and breaks in front of the buyer. Measure beforehand:

CONTEXTO=OnboardingPJ DATTA_API_URL=http://<gateway>:7070 DATTA_JWT=<accessToken> \
  ./scripts/demo/preflight-offline.sh

The script only reads — it changes nothing — and checks five points:

Exit codes: 0 approved, 1 an internet dependency sits on the live demo path, 2 a configuration error in the script itself.

What the preflight does not cover. It measures the demo path, not the whole cluster: telemetry, public negative-base refresh and any scheduled pipeline still want a network, and they fail silently without affecting the demo. Disable the schedules before the event if you want a clean log.