On March 31, 2026, EVE AI Core filed three provisional patent applications with the United States Patent and Trademark Office. Unlike the 81 applications that preceded them, these three were not filed independently. They were drafted as a single, coordinated invention ecosystem — three interlocking families that together define an unavoidable control plane for enterprise AI deployment.
The Problem: AI Without a Control Plane
Enterprise AI today has no equivalent of a network firewall for model outputs. Models generate, actions execute, and audit trails are reconstructed after the fact — a post-hoc forensics problem where the damage is already done before the log entry is written. There is no pre-execution interception point, no runtime cost governance, no cryptographic decision lineage that persists from the moment of generation to the moment of action.
This gap is not theoretical. The EU AI Act, SOC 2 Type II requirements, and an emerging wave of sector-specific AI regulations demand precisely what does not yet exist: a verifiable, auditable record that a governed AI system evaluated a decision, applied compliant rules, and produced a cryptographically signed proof of that evaluation — before the action was taken. The compliance frameworks are written. The infrastructure to satisfy them is not.
Three patent families, filed as a coordinated unit, define that infrastructure.
Family 1: Execution Control (64/022,677)
The anchor patent claims the interception point that sits between AI generation and irreversible execution. Every enterprise AI pipeline has this gap: the model produces an output, and something downstream acts on it. Family 1 claims the governed layer that occupies that gap.
The core mechanism is a 28-stage verification pipeline capable of completing a full governance evaluation in under 100 milliseconds — fast enough to insert between model generation and action dispatch without measurable latency impact on production workloads. The pipeline is not a sequential list of checks; it is a priority-ordered veto engine with six rule classes, evaluated in strict order: governance integrity, charter compliance, dangerous content, overconfident claims, unverified claims, and finally pass. The first rule class that fires terminates evaluation and returns a deterministic verdict. No rule can be skipped. No verdict can be appealed within the pipeline itself.
The Confidence-Reality Divergence scoring mechanism — CRD — is the most technically novel component. CRD quantifies the gap between what an AI system claims to know and what it can actually verify against a trusted knowledge base at runtime. A model that states a fact with 0.95 confidence but can only verify it at 0.40 against the ground-truth store receives a CRD score of 0.55. The pipeline uses this score as an input to the veto decision. High divergence without explicit uncertainty hedging is a blockable offense.
Two implementation details make this patent particularly defensible against design-arounds. First, fail-closed proof recording: if the audit write fails for any reason — disk full, database unreachable, network partition — the action cannot proceed. The system does not degrade gracefully into an unaudited mode; it stops. Second, mid-stream enforcement: the pipeline can halt a streaming response mid-delivery and inject a sovereign refusal. This means the protection applies not just to discrete request-response cycles but to token-by-token streaming outputs as they are being generated.
The claim scope is deliberately broad: any system that performs validation after model generation but before irreversible execution of the model's output navigates this family.
Family 2: Economic Routing (64/022,671)
The second family claims the multi-axis routing decision that determines which model — and at what cost tier — handles a given inference request. This is not a load balancer. It is an economic governance layer.
Seven independent scoring axes produce a composite classification for each request: output length estimation, question depth, presence of reasoning markers, domain complexity signals, conversation depth, instruction count, and semantic ambiguity. The composite score routes the request to one of three tiers — FAST, STANDARD, or DEEP — each corresponding to a different cost envelope, latency budget, and model capability tier. Crucially, the classification is not static: a request that starts at STANDARD can be escalated to DEEP mid-generation if the model's own confidence signals fall below a threshold during generation.
The cost governor operates across three budget scopes simultaneously: daily aggregate spend, monthly aggregate spend, and per-provider spend. When a budget scope is approached, the governor applies one of five enforcement actions in order: allow, warn, throttle, block, or fallback to a lower-cost provider. The enforcement action is deterministic given the budget state — there is no probabilistic sampling, no user-facing randomness. An organization that has consumed 90% of its monthly budget receives throttled responses, not randomly degraded ones.
Provider health is tracked with a six-state machine: unknown, healthy, degraded, failed, cooldown, and recovering. The machine transitions are driven by latency percentiles, error rates, and timeout frequency. A provider that enters the failed state does not receive traffic until it completes the cooldown and recovering states in sequence. This self-healing behavior is claimed as part of the routing invention because it directly affects which cost tier is available at any given moment.
The connection to Family 1 is explicit and claimed: the routing decision determines the governance pipeline's context budget and verification depth. A DEEP-tier request receives a larger context window for CRD scoring and a more exhaustive rule evaluation. A FAST-tier request receives a compressed governance pass. The two systems are co-designed, and that co-design is part of what Family 2 claims.
Family 3: Trust and Compliance (64/030,624)
The third family claims the cryptographic evidence layer that is generated as a byproduct of governed execution and routing. If Family 1 is the decision point and Family 2 is the economic allocator, Family 3 is the proof that both happened correctly.
The trust fabric middleware is the outermost layer: it wraps every request with pre-execution and post-execution evaluation pipelines, producing a weighted trust score from four components. The firewall evaluation contributes 25%. Policy compliance contributes 20%. Regulatory compliance mapping contributes 25%. Charter alignment contributes 30%. The weights are not arbitrary; they reflect the relative audit surface of each component under the EU AI Act's risk classification framework. High-risk system deployments are dominated by regulatory compliance weight. General-purpose deployments balance across all four.
The proof ledger is hash-chained. Each entry incorporates the SHA-256 hash of the previous entry as part of its own hash input. Tamper one record and every subsequent record becomes cryptographically invalid. The chain is not a blockchain — it is a simpler, faster, append-only ledger with no consensus mechanism — but it provides the same tamper-evidence property that regulators require for audit trail integrity.
Sovereign partitions allow multiple tenants to share the same infrastructure while maintaining cryptographically isolated evidence stores. Each partition has a state checksum that changes whenever any record within it changes. Inter-partition messaging is encrypted. A compliance auditor for one tenant cannot, even with physical access to the storage layer, read or modify the evidence records of another tenant.
The regulatory mapping is comprehensive and specific. EU AI Act risk classifications are mapped article-by-article to the obligations each article creates and the system components that satisfy them. More than 25 SOC 2 controls are mapped to specific modules in the architecture. Evidence retention is set at seven years by default, with configurable per-jurisdiction overrides. The specification accounts for GDPR right-to-erasure conflicts with immutable audit trails and proposes a cryptographic redaction mechanism that preserves chain integrity while satisfying erasure obligations.
Decision reconstruction is the feature that closes the compliance loop. Given any request identifier, an auditor can walk the proof ledger chain and reconstruct the complete decision path: which routing tier was selected, which governance rules were evaluated, which CRD score was computed, what trust score was assigned, and what action was taken or blocked. Every step is cryptographically verified. The reconstruction is deterministic — it produces the same result every time, regardless of when it is run.
"To build an enterprise AI product that validates before execution, routes by cost, and proves compliance to regulators — you now have to navigate these three families."
Why Three Families, Not One
A single broad patent can be designed around. Split the module, merge two components, change the implementation order — a sufficiently skilled patent attorney can thread a product through a single claim set. Three interlocking families create a triangular dependency that is structurally harder to escape.
The routing decision feeds the execution pipeline: Family 2 determines the context budget that Family 1 uses for CRD scoring. The execution pipeline generates evidence for the compliance layer: Family 1's veto decisions and audit records are the primary input to Family 3's proof ledger. The compliance layer's regulatory requirements constrain routing: Family 3's EU AI Act mappings determine which routing tiers are permissible for high-risk system deployments under Family 2's cost governor.
These are not administrative dependencies. They are functional ones, claimed explicitly in the specifications and cross-referenced in the drawings. A competitor who builds pre-execution validation has addressed Family 1 but still needs economic routing to manage inference costs at enterprise scale. One who builds routing still needs compliance attestation to satisfy regulatory auditors. One who builds compliance attestation still needs execution control to ensure the evidence being attested is generated at the right point in the pipeline.
The prosecution strategy compounds this through continuation practice. Each of the three families can support three to five continuation applications claiming narrower embodiments, specific implementation variants, and downstream use cases. Three parent filings today become a 15-patent thicket within 24 months of prosecution — without requiring a single additional invention.
The Filing Package
The three applications together comprise 62,563 words across 12 files. Each family contributes a specification exceeding 10,700 words, a drawing set with 12 figures, a figure caption document, and a technical appendix with annotated implementation examples drawn from production code. The specifications are coordinated in terminology: every term defined in one specification carries the same definition when it appears in the other two. This is deliberate prosecution hygiene — claim construction disputes that exploit inconsistent terminology across related patents are foreclosed at the drafting stage.
The anti-design-around work is extensive. Each specification explicitly accounts for: merged and split module architectures, synchronous and asynchronous verification modes, relational and document-based storage backends, symmetric and asymmetric cryptographic primitives, rule-based and learned decision logic, and cloud, edge, on-premises, and air-gapped deployment topologies. A product that moves a component from one service to another, or replaces a hash function with a different one, or runs the pipeline on-device instead of in the cloud, does not escape the claims.
The three serial numbers are 64/022,671, 64/022,677, and 64/030,624. The cross-references between them are bidirectional — each specification cites the other two as related applications, and the claim language in each uses defined terms that trace back to the shared invention disclosure that preceded all three filings.
For partnership and licensing inquiries: The unified control-plane patent stack and supporting strategy document (25,403 words) are available for review. Contact [email protected] for partnership and licensing inquiries.
The three serial numbers are 64/022,671, 64/022,677, and 64/030,624. They represent the first coordinated AI control-plane patent stack filed as a unified system. The 12-month conversion deadline begins now. The moat is real, the mechanism is implemented in production, and the evidence is cryptographically signed.