Expound/Solutions/Aviation, mission & defense

Does this authorization still hold?

A mission operator holds an authorization that was valid when issued, and has no mechanical way to establish that it is still valid now. Stale authority is computed as stale, before action. The authorization itself must remain current, continuously.

The scene

Valid when issued. Valid now?

The mission authorization answers what was approved then, not what is valid now. Nothing in the record is asked to notice the difference, so nothing does.

The exposure is whatever the authorization is wired to. None of it needs a system to fail. It needs a system to keep working on a basis that quietly stopped being true.

This matters most where stale or unauthorized reliance can contribute to unsafe physical control or unauthorized mission action, which is exactly where a mechanical answer to is this still valid is worth the most.

Computed reliance sits beside the existing safety case, the certified control logic and human command. It adds a present-tense, recomputable answer about authority. It displaces none of them.

What gets treated as the same thing

Different facts, one status field.

An authorization that was issued is not an authorization that is still valid. An effect that occurred is not a license to act on it.

Issued then≠Valid now

The effect≠The license to act on it

Identity≠Authority

A record’s presence≠Its issuance

Evidence needed, and what must remain current

What the roster would carry.

What has to be proved is your domain’s knowledge, and it stays with the people who hold it. Finality Assurance™ Standards (FAS) fixes the shape of the list, not its contents.

  • The authority chain
  • Environment state
  • Current validity evidence

Must remain current. The authority chain changes. The environment moves. The authorization itself has to stay current, continuously.

  • The authorization itself, continuously

What changes if reliance is computed

Stale authority is computed as stale, before action.

Whether the authorization currently applies is computed on every read, not stored anywhere. The value read after a basis change is a value no actor wrote.

When the basis moves (the authority chain, the environment state, the window), the authorization recomputes, and the actions that rested on it are found by recorded reliance rather than by someone remembering.

Handling failure is where governed systems differ most from brittle ones. When an observer fails or communications degrade, nobody is forced to choose between ignoring the problem and stopping the mission: the observation obligation becomes UNKNOWN and is named, and where a compensating obligation declared in advance and independent of the failed source is itself discharged, the verdict recomputes to DEGRADED, reliance narrows to the exact decisions affected, and work whose roster is undamaged proceeds.

Human command stays in command. People authorize. Nobody edits the verdict by hand.

The challenges, one at a time

How do you…

Each challenge starts with the question you would actually ask. Then: what most teams do today, what best practice looks like, how Expound delivers it, and what to measure to know where you stand.

Challenge 01

How do you know this authorization is still valid now, not just when it was issued?

Today
The authorization answers what was approved then. Nothing in the record is asked to notice that the environment, the authority chain or the window has moved.
Best practice
Derive current validity on every read from the authority chain, the environment state and current validity evidence. Never store it as a flag.
With Expound
The verdict is computed on every read. Stale authority is computed as stale, before action.
Technical value
The value read after a change is a value no actor wrote.
Business value
Operators stop carrying the question in their heads.
Outcomes
Stale authority is caught before action rather than after.
What to measure
Authorizations recomputed on basis changeStale-authority events before actionTime from environment change to recompute
Challenge 02

How does the mission keep operating when a sensor or a link degrades?

Today
Two choices: ignore the degradation or stop everything.
Best practice
Degrade selectively. Name the failing obligation, narrow reliance to the decisions actually affected, and let undamaged work proceed.
With Expound
The failing obligation is named and becomes UNKNOWN. The verdict moves to DEGRADED only where a compensating obligation was declared in advance, is independent of what failed, and is itself discharged. Any other required obligation at a lower grade still controls the result. Reliance narrows to the exact decisions affected.
Technical value
Resilience is built into the rules, not bolted on as an extra system.
Business value
The mission keeps operating under a fault, with the affected work isolated.
Outcomes
Predictable decisions and withdrawals under faults.
What to measure
Affected-set size per faultUndamaged work proceeding under degradationTime to recovery
Challenge 03

How do you keep human command in command while machines compute?

Today
Automation either bypasses the human or waits for one on every step.
Best practice
People authorize, hold exception authority and decide contested cases. No human edits the verdict by hand, and no machine does either.
With Expound
Humans set policy and hold the declared root authority. Handing off to a person is a route like any other, one the rules can select. The kernel computes; it never approves itself.
Technical value
Exactly one named root; everything between it and the result is reconstructible.
Business value
Command authority is strengthened, not displaced.
Outcomes
Authorizations you can reconstruct, from a chain you can name.
What to measure
Escalations routed by ruleExceptions recorded as named itemsReconstructable authority chains

Field validation

Start with one decision in your domain.

Pick one decision that matters. Write down what it has to prove. We run the rest with you, on your baseline, with the evidence under your control.