Auditable Emergence

Executive Summary

The Solution: Sturna's Galaxy Phase architecture delivers verifiable AI execution with SEC 17a-4 and SOC 2 Type II compliance built in. Every agent interaction is immutably logged. Every decision is traceable to underlying intent and reasoning. Every multi-agent collaboration is attributed and auditable. The system detects and rejects its own errors before they reach users—aggressive, automated quality gates that function as compliance infrastructure.

The Results at a glance:

Sturna isn't faster than traditional orchestration. It's fundamentally different—agents don't wait for routing logic, they compete. The best agent wins. The system learns from every execution. No DAGs. No static workflows. No dead code.

For finance, compliance, and regulated institutions, Sturna is the only multi-agent framework that satisfies institutional governance requirements. It's auditable, verifiable, and built for regulators.

Section 1: The Architecture — Seven Layers of Orchestration

The Galaxy Phase architecture is not a framework on top of LLMs. It's an orchestration operating system—seven interlocking layers that together guarantee verifiable, auditable, self-healing execution at institutional grade.

Layer 1: Intent Engine — The Router That Listens

An intent is not a task. It's a business question expressed in natural language: "What is the compliance status of our Q2 investments against current ESG mandates?" or "Model tax-loss harvesting scenarios across three client portfolios."

The Intent Engine receives the intent, tags it with domain metadata (finance, compliance, risk, operations), and classifies it into one of 12 capability clusters based on semantic analysis. This classification is deterministic and logged—the same intent will always match the same cluster.

Layer 2: Semantic KNN Router — Finding the Right Specialist in 2–5ms

After intent classification, the system queries a vector database of 446+ specialist agents. Using K-nearest-neighbors similarity matching, it identifies 8–12 agents whose expertise best matches the intent's semantic meaning.

An intent about "regulatory reporting timelines" matches agents specialized in compliance, reporting, and risk—not portfolio optimization or trading. This filtering happens in 2–5ms using a pre-computed embeddings cache. No LLM calls. No latency.

Layer 3: Multi-Objective Auction — The Competition

Once the candidate agents are identified, the real orchestration begins: a competitive auction where agents submit proposals simultaneously. Each agent submits a bid with three components:

1. Confidence: Agent's estimated probability of success (0–1)
2. Cost: Predicted token consumption
3. Reasoning: Structured explanation of approach (logged, auditable)

The system scores each bid using:

score = (confidence × domain_relevance_multiplier) / execution_cost

The agent with the highest score wins the right to execute. All bids are logged—even losing bids, with their confidence, cost, and reasoning. This is Sturna's core differentiator: emergent orchestration without static routing logic. No DAGs. No human-written workflows. Agents self-organize through competition.

Layer 4: StarDAG Execution Engine — Parallel Execution

The winning agent executes its plan. But execution isn't linear. The StarDAG engine enables parallel sub-task execution when an agent's work can be split. A portfolio analysis might run ESG screening, tax impact modeling, and regulatory compliance checking simultaneously—not sequentially. Outputs are merged into a unified result.

Every sub-task execution is timestamped and attributed to the specific agent. If one parallel path fails, the system captures which one and why. End-to-end execution averages 21.1 seconds. P99 latency for the routing + bidding layer alone is 340ms—versus 850ms P99 for LangGraph, which uses LLM-based routing on every request.

Layer 5: Triple-Gate Verification — The Quality Gates

Before any result reaches the user, it passes three automated quality gates. Each gate inspects the result from a different angle:

The system is brutal. If a result fails any gate, it's returned with explicit reasoning: "Gate 2 detected: tax impact model fails when client has direct stock holdings. Recommend manual review before serving to client."

Gate 3 in Depth: MARCH — Multi-Agent Red-team Challenge Harness

Gate 3 (Boundary Coverage) is enforced by MARCH, a runtime adversarial verification harness that dispatches three independent Checker agents to challenge every solver output before it reaches the user. What the gate-card above describes as "52% catch rate" is the measurable outcome of this mechanism. This section documents how it actually works.

Why Adversarial, Not Just Automated

Standard automated tests validate outputs against predetermined rules written by the same team that built the solver. MARCH treats the solver's output as an adversary's claim and attempts to falsify it from three independent angles. The distinction matters: a system that validates its own output is less reliable than one where independent agents — with no knowledge of the solver's reasoning — attempt to find faults. This is the red-team principle applied at the verification layer.

Information Barrier Enforcement

The information barrier is the load-bearing guarantee of MARCH. When a solver produces output, that output is withheld from all Checker agents. Each Checker receives only the original user intent — nothing the solver said, concluded, or recommended.

This is not a policy claim. It is enforced programmatically. assertInformationBarrier() is called at the dispatch boundary before each Checker payload is constructed. If solver output is detected in the Checker payload, the function throws and the gate returns a hard FAIL. The barrier cannot be bypassed by accident; it can only be bypassed by deliberate code change.

Three Challenge Dimensions — Three Independent Checkers

MARCH dispatches three Checker agents in parallel, each evaluating the original intent against a distinct risk axis:

• Factual Accuracy Checker (retrieval-first): Focuses on hallucination risk. Does the intent request information the solver might confabulate? Are numerical claims, regulatory citations, or entity names verifiable? The factual checker runs retrieval augmentation before scoring.
• Logical Consistency Checker (logic-first): Focuses on reasoning soundness. Are there internal contradictions? Does the conclusion follow from stated premises? Are there unstated assumptions that could invalidate the output? The logical checker applies formal reasoning patterns before scoring.
• Regulatory Compliance Checker (legal-first): Focuses on compliance exposure. Does the intent touch regulated domains — SEC, HIPAA, EU AI Act, AICPA TSC? Are there specific requirements that must be satisfied? The legal checker consults domain-specific compliance rulebooks before scoring.

Each Checker produces a score from 0.0 to 1.0 (1.0 = no risk detected) and a binary PASS/FAIL verdict at a threshold of ≥ 0.60. The three Checkers run in parallel with a 45-second per-Checker timeout. They do not communicate with each other or with the solver.

Per-Dimension Voting Protocol

Gate 3 requires 2 of 3 Checkers to PASS. This is not an average — it is a democratic majority vote evaluated independently:

march_passed = count of Checkers where score >= 0.60

if march_passed >= 2:
    if mean_score >= 0.85  →  verdict = PASS
    else                   →  verdict = PARTIAL
else:
    verdict = FAIL

A PARTIAL verdict is returned to the user with an explicit annotation identifying which dimension scored below threshold. A FAIL verdict is returned with per-dimension reasoning: "MARCH Gate 3: Regulatory Compliance Checker flagged HIPAA PHI exposure risk (score 0.41). Output requires legal review before serving."

Fail-Closed Default on Deadlock

A 1-1-1 distribution (any combination of one PASS and two FAILs) cannot achieve majority. Under MARCH's rules, failure to achieve majority defaults to FAIL — this is the fail-closed guarantee.

More broadly: any Checker that throws an exception, times out, or returns malformed output is treated as a FAIL vote, not a skip. Infrastructure errors, proxy unavailability, and model failures all default to rejection, not approval. There is no approval-by-default path in the MARCH harness.

Barrier Violation Audit Mechanism

Every Gate 3 execution — pass or fail — is persisted to the march_verdicts table as an append-only WORM record. The audit persistence layer has no UPDATE path. Each record captures:

• MARCH verdict (PASS, PARTIAL, or FAIL)
• Mean adversarial verification score (the adversarial_verification_score field in the Transparency Card)
• Per-checker results: dimension identifier, individual score, binary verdict
• Gate latency in milliseconds
• Intent hash and UTC timestamp

Regulators, compliance teams, or internal auditors can reconstruct the complete Gate 3 decision chain from the march_verdicts table alone. No application-layer access is required. The record exists whether the solver's output was ultimately served or rejected, making MARCH verdicts independently auditable from Transparency Card records.

MARCH deployed to production on May 2026. As of the current writing: 18/18 unit tests passing, 100% pass rate across 10 supply-chain benchmark intents, mean adversarial verification score 0.766, zero barrier violations detected.

Layer 6: Transparency Card — The Full Explanation

Every result includes a Transparency Card: a structured JSON document that shows the complete decision chain:

{
  "intent": "Model tax-loss harvesting for Q2",
  "intent_classification": "portfolio_optimization",
  "candidate_agents": [
    {
      "agent": "Financial Modeler",
      "confidence": 0.92,
      "bid_cost": 1847,
      "reasoning": "Specialized in tax-aware portfolio optimization",
      "won": true
    },
    {
      "agent": "Risk Optimizer",
      "confidence": 0.78,
      "bid_cost": 2104,
      "reasoning": "Risk-first approach suboptimal for tax planning",
      "won": false
    }
  ],
  "execution": {
    "winner": "Financial Modeler",
    "actual_cost": 1823,
    "execution_time_ms": 4127,
    "sub_tasks": [
      {"task": "ESG screening", "cost": 456, "status": "complete"},
      {"task": "Tax lot analysis", "cost": 892, "status": "complete"},
      {"task": "Scenario modeling", "cost": 475, "status": "complete"}
    ]
  },
  "quality_gates": {
    "gate_1_consistency": "passed",
    "gate_2_failure_traps": "passed",
    "gate_3_boundary_coverage": "passed",
    "march_verdict": "PASS",
    "adversarial_verification_score": 0.847,
    "march_checkers": {
      "factual_accuracy": {"score": 0.91, "verdict": "PASS"},
      "logical_consistency": {"score": 0.88, "verdict": "PASS"},
      "regulatory_compliance": {"score": 0.79, "verdict": "PASS"}
    }
  },
  "audit_trail_hash": "0x8a3f7c2b9e...",
  "timestamp": "2026-05-03T14:32:18Z",
  "requestor": "compliance_officer_id_4821"
}

This card is immutably logged and cryptographically signed. Every user action creates an auditable record. SEC 17a-4 requires immutable records — this card satisfies that requirement. SOC 2 requires audit trails — this card is the audit trail.

Layer 7: Emergent Learning — Self-Improvement

Every execution creates a record in the learning system. The system tracks confidence calibration (did confident agents succeed?), cost accuracy, and win/loss history per agent per domain. Over time, a feedback loop forms. An agent that consistently bids high confidence but fails will be deprioritized. An agent that bids conservatively but succeeds gets a reputation boost. Learning is transparent and logged—no black-box feedback.

Section 2: The Four Differentiators

1. Auditable Emergence

Traditional frameworks require humans to write routing logic, design workflows, and specify which agent handles which task. When something breaks, you debug human-written logic. When you add a new agent, you rewrite routing. The framework is static.

Sturna agents compete based on confidence + cost. Adding a new agent is as simple as registering it—it competes immediately. If it's good, it wins. If it's bad, it loses. This is emergence: decentralized decision-making within centralized governance. You define the rules; the system enforces them automatically.

2. Triple-Gate Verification

Most AI frameworks have one quality mechanism: hope that the model is good enough. Sturna has three. See the gate cards above for catch rates by gate type.

3. Cross-Domain Intelligence — 446+ Specialist Agents

Sturna's agent pool spans five tiers: Governance (Compliance Audit, Cost Attribution, Audit Trail, SLA Enforcer, MCP Governance), Risk/Ops (Chaos Engineer, Conduit DevOps, Phantom Security), Enablement (Onboarding Wizard, Intent Debugger, Agent Benchmarker), Specialized (InsForge Engineer, Financial Modeler, Cross-Agent Mediator, Policy Enforcer), and Maintenance (Health Monitor, Versioning Agent, Marketplace Curator).

4. Institutional Observability

Every execution produces a Transparency Card. Sturna provides dashboards to aggregate, search, and audit these cards: all decisions by date/agent/domain/cost, audit trail hash chain (tamper-evident), cost attribution, agent confidence calibration over time, quality gate pass/fail rates, and role-based approvals with timestamps.

Section 3: Compliance Architecture

SEC 17a-4 Alignment: Immutable Audit Trail

SEC Rule 17a-4(f) requires "electronic records must be retained in a non-rewritable, non-erasable format" and "must be alterable only by addition of new data." Sturna satisfies this with:

1. Immutable Event Log: Events are appended only; no updates or deletes.
2. Tamper-Evident Hashing: Each event includes a cryptographic hash of the previous event. If anyone modifies a record, the hash breaks.
3. Timestamping: Every record is timestamped and verifiable against trusted time authority.
4. Retention Compliance: All records retained for required periods (7 years for finance).

SOC 2 Type II Alignment

Compliance Framework Alignment

Tenant Isolation & Encryption

Each tenant's intents, executions, and Transparency Cards are isolated at the database level. Each tenant has its own encryption key. Role-based visibility ensures a trader at Firm A cannot see Firm B's audit trail, even if both use Sturna.

Section 4: Benchmark Data

Latency Performance

Sturna's latency is constant (no percentile tail blowups) because intent routing uses pre-computed embeddings (2–5ms), auction scoring is deterministic (3–8ms), and there are no LLM-based routing calls on every request.

Token Efficiency

Cost Per Intent

Reliability & Recovery

When an agent fails, Sturna's self-healing system detects the failure (triple-gate catches it), logs it (immutable record), re-routes to the second-best agent (next auction), executes an alternate approach, and logs the recovery. Users see the successful result with full provenance—never the failure.

Section 5: Competitive Position

vs. LangGraph (Enterprise Leader)

LangGraph offers flexibility; Sturna enforces best practices. If your team likes writing orchestration code, LangGraph is better. If you want to delegate routing to the system, Sturna wins.

vs. CrewAI (Open Source Leader)

CrewAI has 44K GitHub stars, is free, and is simple. But it has no recovery mechanism, no compliance trail, and maxes out at ~500 agents. Sturna handles orchestration automatically, ships production-grade audit infrastructure, and scales to 1,000+ agents. Sturna costs $49/month; CrewAI is free. But Sturna ships reliable, auditable systems while CrewAI requires you to write orchestration code.

vs. AutoGen

AutoGen was deprecated October 2025. Sturna is the natural upgrade path.

vs. OpenAI Swarm (Minimalist Approach)

Swarm works with OpenAI models only and requires human-specified handoffs. It's practical for fewer than 5 agents with fixed handoffs. For multi-agent orchestration at scale with compliance requirements, Swarm is insufficient.

Market Opportunity

72% of Global 2000 organizations are deploying multi-agent systems (2025). The orchestration platform TAM is $8.2B over 3 years. Sturna's focus on compliance + observability positions it for the governance lane—the highest-margin segment.

Section 6: Conclusion & Call to Action

Regulated institutions—banks, wealth managers, insurance companies, healthcare systems—cannot deploy black-box AI at scale. Compliance, audit, and governance require transparency.

Sturna solves this through architecture, not bolted-on monitoring. Transparency is built in. Auditability is built in. Compliance is built in:

• Immutable audit trail: Every decision is logged, hashed, and timestamped.
• Triple-gate verification: Automated quality control catches 15%–52% of errors before they reach users.
• Emergent orchestration: 446+ specialist agents compete for your work. The best wins. The system learns.
• Institutional observability: Dashboards and exports built for regulators, not just engineers.

To discuss Sturna for your institution, contact hello@sturna.ai. Include: your institution type, approximate intents/month, key compliance requirements, and current AI orchestration pain points. We'll schedule a technical overview and compliance architecture walkthrough.

Appendix: Technical Reference

Triple-Gate Catch Rates by Domain

Agent Tiers & Specialization

Governance Tier (5 agents): Compliance Audit, Cost Attribution, Audit Trail, SLA Enforcer, MCP Governance

Risk/Operations Tier (3 agents): Chaos Engineer, Conduit DevOps, Phantom Security

Enablement Tier (3 agents): Onboarding Wizard, Intent Debugger, Agent Benchmarker

Specialized Tier (8+ agents): InsForge Engineer, Financial Modeler, Cross-Agent Mediator, Policy Enforcer, Schema Migration, Cost Optimizer, Siphon Crawler, Artery Pipeline

Maintenance Tier (3 agents): Health Monitor, Versioning Agent, Marketplace Curator

Plus: 180+ support agents spanning social media, sales, content, research, and specialized finance domains.

Document Version: 1.0  ·  Date: May 3, 2026  ·  Classification: Public  ·  sturna.ai/how-it-works