Sovereign Defense Assurance
Commercial referenceDEF-002
Quote DEF-002 when requesting information, licensing, technical review, or acquisition discussion.
Who this is for
Sovereign defense program directors and national technology authorities requiring customer-controlled operational boundaries and independently verifiable evidence.
The problem you already have
Sovereign programs need review that keeps working when the network doesn't
Sovereign-compatible assurance should not require a mandatory external cloud service for the demonstrated local runtime path. DEF-002 provides a LOCAL_ONLY profile for customer-controlled operation, with release-candidate evidence for loopback binding and non-loopback egress denial under the tested configuration.
Nothing about your source material passes through a third-party LLM or external cloud, by construction
Sovereign custody is implemented through customer-controlled deployment profiles rather than a mandatory public-cloud workflow. In the qualified LOCAL_ONLY runtime trace, DEF-002 completed signed startup and an accepted local request with zero observed connect() calls and zero observed non-loopback destinations.
This is built around your deployment boundary, not around access to it
Never requested: control of your deployment environment or access to sovereign data outside the evidence contract. The demonstrated LOCAL_ONLY runtime path does not require a mandatory external cloud or model service.
Real-World Operational Scenario: The Approval That Went Through Despite the Objection Nobody Could See Later
Scenario: A sensitive action gets approved by a review board.
One reviewer raises a specific caveat during the process — a piece of missing evidence they flag as concerning — but the majority approves anyway.
WITHOUT this check: An approval workflow can leave the final record without a durable representation of the dissent that preceded it. A later reviewer may then be unable to distinguish a risk that was raised from one that was never identified.
WITH this check: The minority objection, referenced evidence gap, decision state, and any supplied override evidence are preserved in the evidence record as tamper-evident metadata. A later reviewer can distinguish a risk that was explicitly raised from one that was never recorded.
What BivectorAI Provides
Disconnected Doesn't Mean Blind
Local verification continues when disconnected from external services, with unavailable dependencies marked as explicit caveats.
Dissent Is Preserved, Never Erased by Approval
A minority objection or flagged evidence gap is preserved in the approval/evidence record as tamper-evident metadata, so a later reviewer can determine that the risk was explicitly raised rather than absent from the record.
Local Evidence Processing Under Your Boundary
In the demonstrated LOCAL_ONLY deployment path, evidence production does not require transmission to a third-party LLM or mandatory external cloud service. Customer-native inputs are normalized locally under explicit format-specific evidence boundaries.
High-Risk Approval Requires an Explicit Override, Not Silence
High-risk approval with missing evidence remains blocked. An override packet can be represented in the evidence contract, but packet presence alone is not treated as verified authority in the current release; operational authority remains with the customer.
Customer-Native Evidence In, Without Pretending Every Format Means the Same Thing
DEF-002 now supports deterministic, provenance-bound ingestion across the tested customer-native approval, jurisdiction-policy, CycloneDX, SPDX, STIX 2.1, OSCAL and domain-event formats. Each format keeps an explicit execution boundary instead of being silently reinterpreted as evidence it does not contain.
- Approval JSON: normalized into executable
APPROVAL_DISSENT_AUDITrequests when the required evidence metadata is present. - Approval CSV: supported under the same fail-closed rule; rows missing dissent detail, required risk mapping or override evidence remain non-executable rather than being completed by inference.
- Jurisdiction policy JSON/YAML: normalized into executable
SOVEREIGN_BOUNDARY_ASSESSrequests with customer-supplied node evidence roots. - CycloneDX JSON/XML and SPDX JSON/YAML/tag:value: normalized into the SBOM evidence owner with explicit supplemental metadata where the native document does not contain the fields required by the evidence contract.
- STIX 2.1 JSON: supported incident records are normalized into incident-forensics evidence, with missing quantitative evidence supplied explicitly rather than guessed from descriptive text.
- OSCAL Assessment Results JSON/YAML/XML: findings and observations are normalized losslessly with source provenance. OSCAL is not automatically treated as a complete sovereign or seven-domain evidence bundle.
- Domain event JSONL: explicitly tagged records are normalized into typed Zero Trust, Incident Forensics, OT/ICS, Sensor and Logistics child-evidence inputs. Unknown or missing domains are rejected.
Evidence boundary: native ingestion is proven under the tested representative formats and format-specific contracts. Direct DEF-002 execution is available only where the normalized source contains the required operation contract; incomplete or unsupported evidence fails closed.
Prove the Gate Before Broader Integration (Zero-Risk Evaluation)
Do not buy the claim. Test the gate.
Disconnect the evaluation environment from the network mid-review, and separately run an approval scenario where one reviewer objects but the majority proceeds. It succeeds only if it continues with explicit caveats in the first case, and preserves the dissent permanently in the second.
This initial trial measures degraded-mode continuity, caveat-disclosure completeness, and dissent-preservation accuracy. Commercial scale-up occurs only after measured results prove value in your own lab environment.
What you provide
Customer evidence already produced by your workflow. Tested representative inputs include approval records, jurisdiction-policy records, CycloneDX or SPDX software-bill-of-materials data, STIX 2.1 incident records, OSCAL Assessment Results, domain-tagged event streams, evidence-seal metadata and dependency-availability records. Required evidence that is absent from the source must be supplied explicitly; DEF-002 does not fabricate it.
What BivectorAI actually hands you
- Degraded-mode continuity and caveat-disclosure classification.
- Dissent-preservation and evidence-gap flags when an objection or missing dependency wasn't carried through to the final record.
- Machine-readable output for API or dashboard integration.
- Traceable report for internal review, acceptance, audit or pilot comparison.
What we will never ask you for
Never requested: control of your deployment environment, sovereign data outside the evidence contract, or your system's core design data. Requests are screened for forbidden sensitive fields and unknown top-level fields before evidence logic runs; malformed or over-broad envelopes are rejected rather than silently accepted.
How it actually runs
What Is Proven Today
DEF-002 is available as a signed release candidate for controlled technical evaluation and integration diligence. The current evidence boundary is based on executable product tests and representative synthetic customer-like acceptance, not on government certification or operational field validation.
- Dedicated DEF-002 runtime: proven under the frozen release evidence.
- Exact five-operation sovereign assurance surface: frozen and tested.
- Signed package, manifest, archive and release receipt: verified.
- Fresh isolated installation: PASS in the representative synthetic customer-like acceptance environment.
- Fourteen representative customer-native input formats: PASS under explicit per-format boundaries.
- Fail-closed negative controls: PASS for unsupported operations, forbidden private-key input and unknown event-domain cases.
- Restart persistence: PASS.
- Human command authority: remains with customer-designated personnel; DEF-002 provides assurance evidence and does not replace human authorization.
Not claimed: named-customer acceptance, operational field validation, DoD ATO, government product certification, CMMC certification, FedRAMP authorization, FIPS validation, Facility Clearance or formal air-gap certification.
Evaluation Acceptance Plan
The evaluation path is designed to let a prime, integrator or mission owner test the sovereign-assurance boundary before broader integration.
- Customer supplies: agreed redacted or representative native evidence and the required policy/acceptance context.
- BivectorAI deploys: the signed DEF-002 package in the agreed local/private environment.
- Native evidence is normalized: deterministically and with source provenance under the supported format-specific contract.
- Supported operations execute: only when the normalized evidence satisfies the required DEF-002 operation contract.
- Negative controls run: incomplete, unsupported or prohibited evidence must fail closed rather than being inferred or fabricated.
- Restart and evidence checks run: accepted behavior, release identity and evidence integrity are checked after restart.
- Decision package: BivectorAI returns the agreed acceptance evidence for a go / no-go integration decision.
Evaluation success means the signed package verifies, supported native inputs normalize deterministically, agreed direct operations execute correctly, unsupported or incomplete evidence fails closed, the local/private boundary remains intact, restart behavior remains consistent and an evidence receipt can be produced.
Commercial Next Step
Start with a controlled DEF-002 evaluation and acquisition discussion. The non-confidential evaluation boundary can be reviewed before NDA diligence, customer-specific acceptance scoping or definitive licensing.
- Option / diligence: On request
- Integration / NRE: On request
- Exclusive field-of-use license: On request
- Annual program: On request
- Revenue participation: Negotiated
These are discussion topics, not a binding offer. Final economics, scope, exclusivity, field of use, integration obligations and acceptance requirements depend on the negotiated program.
Engagement path & current acquisition terms
DEF-002 · Tier B — Mission Software
Secures a defined diligence and exclusive-negotiation period. Any option credit is agreed in writing as part of the signed commercial terms.
Starting integration engineering, customer-safe adaptation, local/private deployment work, validation and acceptance evidence for the agreed environment.
Scope-dependent consideration for negotiated exclusivity in a defined field, program, platform class, territory and rights scope.
Engineering support, update access, security maintenance, evidence infrastructure and agreed sustainment services.
Applied to attributable net program revenue under the definitive agreement, subject to negotiated exclusions and accounting rules.
Commercial boundary. These are indicative starting terms, not a binding offer. Final price depends on exclusivity scope, field of use, territory, sublicensing, technical-data rights, integration obligations, export-control review, support requirements and definitive agreement.
IP boundary. Exclusive FOU does not automatically transfer ownership of BivectorAI Background IP. Worldwide/all-defense rights, sublicensing, source-level technical-data rights or assignment require separate negotiated consideration.
Controlled commercial surface
A controlled backend assessment surface currently exists for this capability.
Private / on-premise integration onlyNo automated PayPal checkout. Access is granted only under negotiated commercial entitlement.
Rights structure
Exclusive rights are defined by field of use, program scope, territory, term, sublicensing and technical-data rights. Underlying BivectorAI Background IP remains owned by BivectorAI unless expressly assigned.
Annual sustainment
May include updates, integration support, security maintenance, evidence infrastructure, validation support and agreed engineering services.
Revenue participation
Applied to attributable net program revenue under a definitive agreement with negotiated exclusions, reporting and audit terms.
Scope the DEF-002 diligence and integration boundary
Request DEF-002 Acquisition Discussion →Email fallback: contact@bivectorai.com
Defense technology is integrated through qualified local/private engagement. No public Defense API and no automated Defense checkout are provided.