What Onboarding Requires — The Customer Checklist

This document answers one question: what does your organisation need to have, decide, and provide before an Only Institute deployment goes live? It collects what the offer sheet, the DGV gate documentation, and the integrations page each say in part — updated for everything that has shipped since.

It also states, plainly, where we are stronger than the alternatives and where we are not. A vendor that hides its gaps in an onboarding doc will hide them in production.

The three layers you are buying

Only Institute is not one product. It is three layers that compose, and a customer may adopt them separately or together:

Layer	What it is	What it replaces
DGV gate	The enforcement service. Every governed action is authorised at proposal time (T₀) and re-verified at execution time (T₁); both outcomes produce a signed receipt. Sealed agent-to-agent transport and token delegation ship with it.	Nothing — it sits in front of whatever you already run
PrimeSwarm	The agent platform: governed durable memory (the Continuity Ledger), provenance enforcement, fairness gates, PII sanitisation, human-binding contracts, scheduled work.	The unaccountable-agent pattern — agents that act, log, and cannot prove authority
TPNN	The mathematical substrate: topological constraints on computation that make certain attack classes (prompt injection, out-of-manifold redirection) incapable of forming valid outputs.	Heuristic detection — "probably didn't get injected" becomes "cannot form"

Minuta CRM is where all three run in production today — the live proof, and for most customers the first deployment surface.

What we need from you

Onboarding fails for predictable reasons. These are all of them.

1. Answers to eight questions — or a node map

The Guard intake asks eight questions about your write paths, your agents, and your humans. If you can answer them, onboarding starts immediately. If you cannot — and most cannot — the assessment lite ($4,900, 3–5 days) produces the node map first. Neither is optional: the gate must know every path an agent can write through, because an ungoverned path is not a governed system with a gap — it is an ungoverned system.

2. An identity provider we can sit in front of

The gate binds every action to a verified principal. In production that means a real JWT issuer: your Okta, Entra ID, Google Workspace, Ory, or any OIDC-compliant provider. We do not replace your IdP and we do not want to — your joiners/leavers process is the revocation root, and that is exactly what should control agent authority.

For the gate specifically: DGV_OIDC_ISSUER pointed at your issuer's discovery document, or DGV_JWT_JWKS_URL pinned at a JWKS endpoint you control. The gate refuses to start if the configured issuer cannot be discovered — a typo'd issuer is a fatal error, not a silent downgrade.

3. The write-and-spend surface

Which systems can your agents write to, and which calls spend money? In Minuta the governed surface is 18 tools — every record write and every credit-spending enrichment call. For your deployment we need the equivalent inventory: the CRM objects, the vendor APIs, the email/file actions. That inventory becomes the policy set — signed, versioned, rollback-able — and the answer to "what exactly can the agent do."

4. Somewhere for it to run

• Guard: runs in our VPC. You provide nothing but the answers above.
• Estate: runs in your VPC or on-prem. We need a host with a public (or internally routable) endpoint, DNS, TLS certificates, and a Postgres instance. The deployment bundle (docker-compose.gate.yml, nginx.conf, deploy-check.sh) is ready; deploy-check.sh is the proof — it fails the deployment unless JWT verification, admin auth, fail-closed partition policy, and storage connectivity all hold. We will not call a deployment production if it fails.

5. Named humans for the bindings that matter

Send-to-buyer, file-with-regulator, spend-over-threshold: these stay YELLOW — gated until a named person binds. We need to know who those people are, per action class. The approval workflow is real: policies can require N verified approver signatures, and a token that lacks them is refused at T₁ with a receipt that says exactly how many were required versus received.

6. One decision: what evidence your auditors get

Every governed decision produces a signed receipt — run id, decision hash, Ed25519 signature — re-derivable by anyone holding the verifying key. Decide who sees it: your compliance team gets the evidence surface (the CRM's Settings → Governance view, or the /verify/:run_id endpoint), your SIEM gets forwarded receipts, your auditors get the audit package. The receipts are self-verifying; an auditor does not have to trust our logs.

What you keep — how we fit your stack

The deployment model is sit-in-front, not rip-and-replace:

Your layer	What happens
Your LLM provider	Unchanged. Azure OpenAI PrivateLink, Bedrock VPC endpoints, Vertex, self-hosted — the gate is model-agnostic. Tokens stay on your bill, never ours.
Your IdP	It becomes the trust root. Okta/Entra/Google/Ory issue the tokens the gate verifies; your offboarding revokes the agent's authority with the human's.
Your agents and frameworks	LangChain GovernedTool / govern_all_tools and the CrewAI adapter put the gate in front of agents you already have — verified against the real packages, not docs. Any framework not covered uses the plain HTTP API: POST /govern, POST /execute.
Your SIEM	Receipts forward as structured JSON — Splunk HEC, Datadog, ELK, QRadar, or any webhook.
Your document systems	iManage, NetDocuments, SharePoint, FHIR-based EHRs — knowledge boundaries map to your existing permissions.
Your network boundary	Estate deployments run inside your VPC or on-prem; regulated data never traverses our infrastructure.

Where another governance layer already exists — a DLP, an existing policy engine, a programme of record — we sit in front of it, not instead of it. The offer sheet says this explicitly and it is still true: sit in front of Ory, Okta, or Entra — do not replace them. Sit in front of IBM or Credo — do not replace them.

What is new since this document was last true

• Sealed A2A transport (dgv-sealed-v1). Agent-to-agent payloads are now encrypted end-to-end — X25519 ECDH + ChaCha20-Poly1305 through a zero-knowledge relay, with payload_hash binding the exact authorised ciphertext. The gate authorises delivery without ever seeing plaintext.
• Token delegation (dgv-delegate-v1). A token's grantee can mint strictly narrower child tokens — same tool, parameter subset, shorter expiry, bounded depth. Revoking the orchestrator kills every delegated descendant at T₁. This is the gate-level version of the kill switch: real, tested, cascading.
• The evidence surface. Governed calls in Minuta are inspectable at Settings → Governance — including denials. governance_denied and execution_denied are evidence rows, not silent failures.
• Fact admission verdicts. The agent's memory writes now return admitted / quarantined / rejected with conflict evidence — a second identity claim for a field is quarantined, not silently overwritten.
• Verified deployment posture. deploy-check.sh passed end-to-end on a real Postgres + RS256-JWT instance. Forged, missing, and malformed tokens are denied with signed receipts.
• A bug worth naming. Under JWT auth, tokens bind to the token's sub — and we found and fixed the case where a mismatched executor identity would have denied every governed call at T₁. The verification caught what the type system could not.

Where we are stronger — and where the alternatives are

Stronger here:

• Evidence vs logs. A signed, re-derivable receipt for every decision — yours to verify without our cooperation — is a different category of artefact than a log line.
• T₀ ≠ T₁ enforcement. Authorisation is re-checked at execution. "I was allowed earlier" is not authority — tested live by revoking a caller between the two moments.
• Authority that can only decay. Delegation narrows; it never widens. Most frameworks let a sub-agent inherit or exceed its parent's scope.
• Fail-closed as default. Unreachable authority store means deny, everywhere — partition, restart, and OIDC misconfiguration all fail safe.
• A compliance officer can read the policy. ONLY Lang scripts are governance statements, not Python conditions.

Honest about where others are stronger: Microsoft's Agent Governance Toolkit covers sandboxing and execution isolation, a multi-agent trust mesh, SRE tooling, and 14 framework integrations — all broader than ours. If your threat model is process-level isolation or you need the full framework matrix today, evaluate it seriously. Our comparison paper says exactly where each is stronger, in their words and ours. The two are complementary: AGT can sandbox the process; we govern the decision.

What onboarding is not

• Not certified. DGV test cards map to SOC 2, ISO 42001, the EU AI Act, and the OWASP agentic list — a letter exists when an auditor signs it, not before.
• Not a rip-and-replace. Nothing in your stack is displaced; the gate adds a checkpoint and a receipt.
• Not magic. The catalogue is implemented and tested; some items on the offer sheet remain assessment-only or roadmap — the sheet names them, and so does the product.
• Not your LLM bill. Tokens are never on our invoice.

How it starts

1. This document.
2. The eight questions at /quote — or the assessment lite if you cannot answer them.
3. A named human sends the portal. Guard may accept; Estate and Federation begin with assessment.
4. The gate goes up, deploy-check.sh proves the posture, and the first governed write produces a receipt your auditors can verify without calling us.

An agent does not email you. An agent does not price you. A person binds every send.