The infrastructure
Adverant Nexus: what actually runs underneath Honestas
Six mechanisms carry every claim, every certificate, and every AI call this platform makes. This page names them, in the order a request actually crosses them, for the people who have to trust the plumbing — not the pitch.
A · DISPATCH
Every compute call crosses one orchestrator
Every AI call and every long-running job in Honestas — a document review, a CAT run, a certificate seal — dispatches through UNO: nexus-orchestrator hands durable, multi-step work to nexus-workflows. Nothing in the platform calls a model or an engine directly. One path means one queue, one retry policy, and one audit trail for every action the system takes, regardless of which product asked for it.
FIG.01 — Dispatch ladder, T1–T5
T1
Inline
◆ live
T2
Callback + your data
◆ live
T3
Accelerated
⧖ designed
T4
Long-running
⧖ designed
T5
Verified
⧖ designed
Nothing reaches a model, an engine or a queue around this path. A diagram showing a surface calling an engine directly would be a defect, not a shortcut.
Every dispatch crosses this one endpoint(shipped)nexus-orchestrator:8080 · POST /api/v1/dispatch
B · MODEL ACCESS
Callers never hold a credential
Workflows and the orchestrator never hold an API key. They express a wish — a preferred provider, a preferred model, a capability profile — and the AI Provider Router is the only thing that can turn that wish into a call. It resolves the provider, model, and key from the organisation’s own AI-provider pool, honours the wish only when that org has the provider enabled and credentialed, and substitutes automatically when it hasn’t. Every organisation brings its own keys and its own billing — there is no shared platform key hiding behind a tenant.
FIG.02 — Wish → router → provider, one credential owner
Caller expresses a wish
A preferred provider, a preferred model, a capability profile — never a key.
Router resolves the pool
The org's own AI-provider pool and routing policy decide what actually runs.
Adapter calls the provider
Only the router-chosen adapter ever presents a credential to a model provider.
Spend gate
A FinOps check sits inside the same dispatch path, not bolted on after the call.
The org-owned key pool the router resolves from(shipped)auth.organization_ai_provider_keys · mig 214
C · TOOL SELECTION
A chat turn narrows a large registry to one call
Inside a chat turn, the tool-selection engine narrows the shared tool registry with a two-tier lookup — a semantic pass over what the request is actually asking for, then a structured match against what each tool accepts — before a call is bound and invoked. This path exists for chat. Dispatch and deploy do not go through it; they call UNO and the deploy bridge directly.
FIG.03 — Two-tier tool lookup, chat path only
Semantic pass
An embedding search over the registry surfaces tools that plausibly fit the request.
Structured match
Candidates are checked against what each tool's schema actually requires and returns.
Bind & invoke
Exactly one tool call is bound to the request and invoked — never a guess across several.
The registry every chat-path tool call is matched against(shipped)uno.tool_registry
D · MEMORY
One cycle, not a growing pile of context
Every organisation’s memory runs one cycle: Observe takes in what happened, Derive extracts what it means, Dream consolidates it against what the org already knows, Recall surfaces it back when it’s relevant, and Forget retires it — deletion on request is part of the loop, not a separate process bolted on afterward. HERA, the cross-session recall layer, only ever reads within one organisation’s own history, and only when that organisation has opted in.
FIG.04 — The CMA memory cycle, five stages
Forget cycles back into Observe — the loop never terminates on its own.
The cyclical memory pipeline every org's context runs through(shipped)nexus-graphrag · Observe → Derive → Dream → Recall → Forget
E · GOVERNANCE & ISOLATION
Every decision is evaluated, sealed, and walled off
Every decision Honestas makes is evaluated against a written policy — Cedar, an open-source policy engine — at one of four escalating trust tiers, and the result is appended to a tamper-evident hash chain: a sealed decision can be checked later against exactly what was true when it was made.
FIG.05 — Trust ladder, T0–T3
Isolation is enforced the same way — as a platform mechanism, not a per-product habit. Every read and write is scoped on three axes, inside a Kubernetes cell sealed by default-deny network policy and mutual TLS, so one product cannot reach another organisation’s data even by accident.
Tenant
organization_id — every row belongs to exactly one organisation.
Owner
owner_user_id — a mailbox, a harvest, a derived graph: private even inside one org.
Unit
business_unit_id — optional, scopes further within an org when a business needs it.
What evaluates every decision and walls off every tenant(shipped)Cedar policy engine · Kyverno default-deny · mTLS
F · EVIDENCE & DELIVERY
Code reaches production through one bridge
Code moves from build to running through exactly one path — the forge build system, to ndm, the deployment-manifest registry, to Argo, which reconciles the cluster — never a manual image swap, never a break-glass deploy. Three gates sit inside that one path.
FIG.06 — Build to running, one bridge, three gates
The one bridge every deploy — no exceptions — moves through(shipped)forge → ndm → Argo
Continue reading
See this run inside a real claim on How it works, see where it sits in your own stack on Where this sits, or read the API surface on Developers.
Four working papers. A person sends the one you pick — no download wall, and no meeting is booked.
Work out what this costs