Architecture & Security
What moves, and what never moves.
One diagram carries the whole design. The sealed build reaches only the firm's own database, vector store, model endpoint, and directory; market data and the execution feed are inbound connections on the roadmap. The dialogue circulates between trader and coach and never leaves that plane. Committed plans cross one boundary, to the officer register. Orders travel the firm's own execution path, which runs around this system entirely. And nothing, of any kind, leaves the tenant.
Architecture: what moves, and what never moves.
THE DIAGRAM AS TEXT
- Market data arrives with its connection, which is roadmap: no feed is connected in the sealed build. Nothing flows out, today or then.
- The coaching dialogue circulates between the trader and DJ on the trader plane. It is private: never summarised, scored, or forwarded.
- When a trader commits a plan, that plan crosses one boundary, from the trader plane to the firm plane, where it is evaluated against the mandate.
- Risk and compliance read observations and records from the firm plane.
- Orders run through the firm's own OMS and broker, around DojiPad entirely. The system holds no order routing or blocking capability.
- An execution feed from the OMS back into the system is roadmap. It is not connected.
- Egress: none. No route out of the tenant exists.
The entire system deploys inside the firm's own cloud subscription, under the firm's identity provider and the firm's keys. There are no external calls, no telemetry, and no vendor infrastructure the firm's data could reach. The vendor cannot see the firm's trades. That is a property of the architecture, not a contractual promise.
The firm plane carries mandate evaluations, observations, and evidence chains, and is built for risk and compliance officers. The trader plane carries the coaching dialogue itself and is structurally separated: never summarized, scored, or flagged across. Coaching runs on candor, and candor requires a boundary that cannot be reconfigured away.
Predictions are made at each committed plan and scored against what the trader does next. The scoreboard is on the board, per trader, as forecast against realised. Scoring against fills is the execution horizon and arrives with the execution feed.
- DEPLOYMENT
- Single tenant, firm cloud subscription · Microsoft Azure, firm region, firm keys
- IDENTITY
- Microsoft Entra ID · firm directory, role separation between officer and trader surfaces
- DATA EGRESS
- None · no external calls, no telemetry, no vendor endpoint
- EXECUTION PATH
- Not in it · the system holds no order routing or blocking capability
- RECORDS
- Append only evidence chains · plan, evaluation, observation, acknowledgement ledger, attestations
- GOVERNANCE
- Regulatory alignment memo · available in advance of a briefing on request; architecture review with the firm's security function, under NDA
What the tenant contains, precisely.
Inside the firm's tenant: the application; the model endpoint as an Azure OpenAI resource in the firm's own subscription, referenced by the deployment and never created or held by the vendor; the data VM, carrying the firm's records on its own persistent disk that outlives any redeploy; the gateway that fronts the sealed network; and the firm's Entra directory for identity. The evidence sink, flow-log storage and the log workspace, lives in the tenant too.
Outbound traffic from the sealed network is denied by default. The only application egress the policy allows is the tenant's own model endpoint and Entra for token verification; in the sealed mode that enforcement is always on and cannot be weakened by configuration. Outside the boundary: everything else, including the vendor.
The deployment produces its own evidence.
No badges hang here. Three artifacts, produced by the deployment's own tooling.
- EGRESS MANIFEST
- Generated from the same registry the runtime enforces, so the document cannot drift from the policy: every network family the server can open, with hosts, purpose, and protocol, per deployment mode. A stale manifest fails the build gate.
- FLOW-LOG VERIFICATION
- The tenant's own Azure flow logs, classified flow by flow against the manifest: allowed and expected, allowed but unexpected, denied, or infrastructure. The run includes a deliberate denied-egress probe and fails unless that probe shows up denied, because an empty log is not evidence of a sealed box.
- PLANE-DENIAL REPORT
- A role-by-surface access matrix written for a compliance reviewer: which roles reach each oversight surface, what a denied caller receives (a 404, never a 403), and the structural guarantees that firm-plane routes cannot read trader-plane records. Every row is re-verified live against real routes and a real database on every gate run.
These are reviewed live with the firm's security function under NDA.
Entra groups map to capabilities.
Entra ID groups map to trader, desk manager, risk, compliance, auditor, and strategy. Officer surfaces are gated by capability, not by convention. Org administration is not oversight: an administrator's rights do not include reading the register.
The firm's records, under the firm's policy.
Records are append-only and live in the firm's own storage under the firm's retention policy. Every oversight surface prints an audit-stamped PDF on demand.
What a review under NDA covers.
- The network topology of the sealed deployment, live in the tenant.
- The egress posture, verified against flow logs rather than asserted.
- The plane separation, demonstrated from an officer seat and a trader seat.
- Identity: Entra groups, role mapping, and what each capability gates.
- The record path: where evidence chains live, and how they export.
The two-page security brief covers the boundary, the evidence, identity, and retention: read it as a page or download the PDF.