Mission authority is not technical capability

A system may be technically capable of an action without remaining authorized to perform it. Mission assurance examines the complete mission thread: identity, delegated authority, policy, operational conditions, trusted context and potential consequences.

BIT is being designed to make those dependencies explicit and enforceable at the point of action. It does not create legal authority or replace human command responsibility.

Defined outcomes when conditions change

BIT uses one canonical decision vocabulary. The terms are control outcomes, not claims that the wider system is safe or certified.

ALLOWCONSTRAINDEGRADEHOLDDENYABORT
CONTINUE

ALLOW / CONSTRAIN

Proceed under the active policy, or continue within explicitly narrowed limits.

RESTRICT

DEGRADE / HOLD / DENY / ABORT

Reduce capability, pause, reject or terminate according to the authorized response.

Authority depends on trusted context

Where an action depends on location or verified world state, BIT is being designed to use the Localization Trust States TRUSTED, DEGRADED, CONFLICTED and UNTRUSTED.

Valid mission authority should not automatically permit a location-dependent critical action when the reference frame is conflicted or untrusted. The DEGRADE outcome and DEGRADED trust state remain distinct concepts.

Designed to complement existing architectures

BIT Mission Assurance is designed to complement state machines, policy decision and enforcement points, safety monitors, runtime-assurance functions, command-and-control systems and platform controllers.

It does not replace platform safety engineering, rules of engagement, operational approvals, human responsibilities or domain-specific certification.

Evidence across the mission thread

Each consequential decision should be reconstructable: what the system observed, which policy and authority were active, which state was assigned, what outcome followed and what action occurred.

BIT is developing integrity-protected evidence intended to support TEVV, assurance cases, incident analysis, change control and accountable human review.

Frequently asked questions

What is mission assurance for autonomous systems?

It determines whether a system can continue a mission within defined authority, policy, operating conditions and risk limits—not merely whether its components remain functional.

Is mission assurance the same as AI safety?

No. AI safety is one input. Mission assurance also addresses operational authority, world-state confidence, communications, platform condition, human roles and consequences.

Which platforms can it support?

The architecture is intended to be platform-independent. Applicability must be demonstrated for each platform, mission and operational design domain.

Does BIT certify autonomous systems?

No. Certification and approval remain specific to the regulator, domain, platform, intended use and complete body of evidence.

Sources and technical basis

  1. DoD Instruction 3020.45 — Mission Assurance Construct — Reference inclusion establishes technical context only; it does not claim conformity, approval or certification.
  2. DoD Directive 3000.09 — Autonomy in Weapon Systems
  3. NATO — Summary of the Autonomy Implementation Plan
  4. NIST Artificial Intelligence Risk Management Framework

Start with one critical mission thread.

Map the authority chain, operational dependencies, degraded states, required outcomes and evidence needed for a scoped mission-assurance pilot.

Request technical briefing

Unclassified · scoped workshops and pilot design