Capabilities › Quant v1.1 › AI Governance Control Plane
Where AI Advice Meets Institutional Discipline
No AI, API, agent, or advisor model can bypass the governance layer to reach critical business execution systems directly.
This is the layer in Quant v1.1 built specifically for AI governance. Its job is not to make decisions in place of humans, but to ensure that AI advisor suggestions, research system outputs, and human discretionary instructions all enter business flow through one path — typed, reviewable, replayable, requiring human approval.
AI can suggest and analyze — but cannot bypass governance, approval, or audit to reach critical execution.
Why this page maps to Capability 01
"AI Governance & Approval Closure" as a core yunforce capability needs a real, pressured, externally inspectable system to validate it. Quant v1.1 chose a high-risk experimental scenario — AI advisors, quant research, and human judgment all wanting to move capital — and built a complete governance control plane inside it.
This is not a minimum viable demo. It's a complete, runnable, pressure-testable governance implementation. What follows on this page is how this governance actually lands inside Quant v1.1.
Why this governance is required in 2026
AI models can now produce credible business suggestions. Research systems keep producing solutions. Frontline decision-makers have their own discretion. Every one of these is a legitimate decision source — and every one of them, on its own, is a way for critical business action to proceed without an accountable owner.
"Sophisticated AI output is the easy part. Sophisticated governance over that output is the part everyone underbuilds."
Advisor models have arrived
Gemini, GPT, internal copilots, and human analysts are all producing business-shaped suggestions. Treating them as input is inevitable. Treating them as governed input is the choice.
Audit expectations are rising
"An LLM said so" does not survive compliance review, internal post-mortems, or incident investigation. Decisions need actor, timestamp, version, and policy lineage attached.
Bolt-on integrations leak risk
Wiring AI directly into critical business systems is fast — and that is exactly the pattern that creates the next preventable incident. The seam belongs in governance, not in execution.
Five principles enforced in code, schema, and tests
These are not aspirational values. They are enforced in code, schema, and tests. Every deliverable has to honor all five.
Only authorized systems execute
No agent, model, or API path bypasses governance to reach execution. Full stop.
Approval is mandatory
Risk check allow is approval-eligibility, not execution authority.
Typed inputs only
Free text never becomes executable. The Normalizer is the only entry.
Versioned concurrency
Optimistic locking. Stale approvals fail with a precise reason.
Replayable audit
Every transition emits an immutable event. State is reconstructable.
The content below enters the specific Quant v1.1 scenario. If you only care about the AI governance capability itself, you can skip to the bottom of this page.
One governance plane, four users, four kinds of value
The same governance control plane changes shape depending on who you are at the table. Here is what each stakeholder gets.
Portfolio Manager / Trading Desk
"I want to use AI advice and discretion without giving up control over what trades."
- -Approval is yours, single-commit, version safety
- -Risk MCP runs before approval and before execution; no surprises at execution
- -Stale or expired intents are blocked by design
- -Multi-leg spread support without bespoke plumbing
AI Advisor / Vendor Integration
"Give me a clean integration boundary and I will respect it."
- -One submission API; deterministic typed rejections, not silent failures
- -Idempotency built in — retries are safe
- -Three intent types cover position, risk, and spread strategies
- -You never need a broker credential, ever
Compliance / Auditor / LP Review
"Show me who decided, when, on what version, and why."
- -Immutable audit log under the audit_service identity
- -Approval actor + role + timestamp on every executed decision
- -Risk decision lineage with policy version stamped
- -Full replay from event log; reconciliation by construction
Operator / SRE
"Don't break what already works."
- -Daemon startup does not depend on a remote API
- -Reads a local read-only approval projection
- -Restart-safe execution idempotency by deterministic key
- -The governance layer is additive; the legacy path keeps running until you cut it over
Walk one suggestion through the system
Walk a single advisory suggestion through the system from raw text to filled order. This is the lifecycle every governed object follows. No shortcuts.
Submitted
Advisor (model or human) submits a typed advisory payload. Idempotency keys de-duplicate retransmits.
Normalized
The Normalizer is the only path from free text to typed intent. Ambiguous? Rejected with reason.
Validated
Risk MCP returns a typed decision: allow, warn, deny, or require_adjustment. Policy version stamped.
Approved
The human approver approves the latest version. Actor, role, timestamp, and version recorded.
Executed
The execution system revalidates risk, executes via the broker, and links every fill back to the intent. Audited end-to-end.
What's invariant about this story: at no step does the AI model touch execution directly. Risk check cannot grant execution authority. Approval cannot skip validation. Execution cannot skip approval. These aren't conventions — they are enforced by control-plane code and database schema.
This governance layer lets us absorb new AI decision sources — advisor, research system, or human discretion — without buying a governance failure on top of a new capability. This is the kind of AI system yunforce sets out to deliver.