#ZABAZINGO Cortex — Engine Registry

Cortex is the internal brand name for every AI and recognition engine that reads, understands and searches documents across ZABAZINGO products. This page is the authoritative source for engine names. External vendor names (Mistral, LlamaParse, Claude, …) never appear in any interface, API response, export or contract text — they are translated into Cortex codenames at the presentation boundary.

#Two hard rules

1. No vendor name leaves the building.
   Which provider powers an engine is operational internals. Users, customers, partners, screenshots and exports only ever see Cortex <NAME>. Swapping a provider must be invisible at every surface.
2. The brand is ZABAZINGO. adam-eve is an internal platform/tenant label and is not used externally. Every user-facing wordmark, title tag and doc reference reads ZABAZINGO.

Both rules are operating law, not styling. They take precedence over convenience.

#The Cortex family

Naming scheme: one short, uppercase word from the vault/mineral/oracle field — matching the warm-dark ZABAZINGO CI with its bronze accent. The provider column lives only in this internal doc.

#What each engine does

• SLATE — the free fast reader. Solid printed-text recognition at no extra cost; the default for every upload.
• ONYX — the premium reader. High accuracy on handwriting, poor scans and photos. Kicks in when SLATE is not enough or the user picks Premium.
• PRISM — the structure reader. Breaks tables, forms and multi-column layouts into clean machine-readable structure. Preferred automatically for table/multi-column documents.
• SCRIBE — field extraction. Pulls structured fields (e.g. counterparty, term, notice period) from recognised text, each with a confidence; uncertain values are flagged for review, never set silently.
• LEX — clause and risk analysis. Detects canonical contract clauses (auto-renewal, short notice, price increase, penalty, liability, exclusivity, data protection, long lock-in) and rates the risk.
• ORACLE — semantic search across the whole vault ("reads your cloud"). Answers natural-language queries over all documents.
• ECHO — the independent second opinion. Cross-checks and verifies other engines' output.

#Architecture — a single source of truth

The vendor-id → codename translation lives in exactly one place:

cloud-adam-eve/lib/engine-codenames.mjs   (registry + resolution)

The registry maps each vendor/model id to a Cortex record and exposes three helpers:

• codename(vendorId) → bare codename, e.g. "mistral-ocr-latest" → "ONYX". Drop-in wherever a raw engine id was printed.
• engineLabel(vendorId) → full label, e.g. "Cortex ONYX", for headings and badges.
• sanitizeKeys(obj) → rewrites objects whose keys are vendor names (provider/accuracy maps the UI iterates over): { mistral: true } → { ONYX: true }.

Resolution is tolerant (substring, longest match first), so both mistral-ocr-latest and a bare mistral resolve correctly. Unknown ids fall back safely to the family name CORTEX — never to a vendor name.

#Swapping a provider — the one-line procedure

When a provider is replaced (e.g. ONYX no longer runs on Mistral OCR):

1. Point the affected VENDOR_MAP row at the new vendor id in the registry.
2. Update the Cortex record's vendor note (internal doc note only).
3. Update the provider column in this doc's table.

Codename, UI, API, exports and contracts stay unchanged. That is the whole point: nothing changes on the outside.

#Adding a new engine

1. Add an entry to ENGINES with a codename (vault/mineral/oracle word), tier, label, blurb, vendor.
2. Add row(s) to VENDOR_MAP for the vendor/model ids.
3. Extend this table.
4. If it introduces a new tier, check the product/pricing tier against the existing ones.

#Scope

Cortex names apply to every ZABAZINGO product using these engines — vault/documents, contracts, receipts and all future ones. If a raw vendor name surfaces anywhere (UI text, API engine field, status/accuracy table, export, audit text), that is a defect and is fixed via the registry, not by local rewriting.