Authority and reconciliation
Core governs proposals, issues limited grants, and reconciles outcomes using read-only observation. Its role excludes direct mutation of the target.
Technology / Aetheria
Keep authority attached
to the action.
A request such as “take care of this” can leave an AI system choosing the recipient, amount, record, or timing. Aetheria is designed to check those choices against the authority the organization has actually delegated.
Discuss a technical evaluationHow it works
A permission needs
to survive the details.
Approval of a task can become ambiguous once software chooses how to carry it out. The design therefore binds authorization to a specified action: who is acting, what will change, which target is involved, and what conditions must still hold.
An action that changes materially returns for authorization. A standing mandate can cover repeated work within its limits; human review is required where the organization’s policy calls for it.
Aetheria is in development. The architecture below describes the design; current review material and evaluation requirements appear later on this page.
- 01
Use permitted information
The Aggregator retrieves context and coordinates reasoning within the applicable access and disclosure rules. The resulting proposal identifies the intended work.
- 02
Bind and authorize the action
Core evaluates the specified action against the governing policy and delegation. If the required authority cannot be established, execution does not proceed.
- 03
Execute within the grant
Nullius receives a limited authorization grant and checks its conditions before using the target’s execution credentials. It cannot enlarge the grant.
- 04
Check the external result
Read-only observation checks the target separately from the executor’s report. Reconciliation preserves a mismatch or unresolved result instead of turning it into a success.
Architecture
Separate responsibilities
at the execution boundary
The component that authorizes a change does not hold the target’s writer credential. The executor holds that credential but cannot authorize its own work.
Protected execution
Nullius holds the target’s execution credentials and enforces the grant it receives. A different action needs a new authorization.
Assurance
StilleNacht challenges the controls through adversarial cases and artifact checks. Each campaign needs a stated scope; independence also depends on how the review is run and who controls it.
Atlas and the Aggregator
Atlas is the operator console for requests, review, and progress. The Aggregator retrieves context and coordinates cognition. Neither can substitute its own judgment for authorization, and neither holds the target’s writer credential.
How this relates to existing controls
Identity systems, access policies, and workflow engines already perform important parts of authorization. Aetheria’s focus is the relationship between the original delegation and the particular action selected during an AI-supported workflow, including changes, retries, and uncertain results. An evaluation should establish where additional controls help and where existing mechanisms are sufficient.
The control model
The organization
sets the mandate.
A technical check can establish that an action fits a policy. The organization remains responsible for whether that policy gives someone appropriate discretion, and how people affected by a decision can question it.
Read the textbook’s first quarterOutcome evidence
Did the refund
actually happen?
A workflow reports success, but the payment ledger is unavailable. Sending the refund again could create a duplicate. Calling it complete could leave the customer waiting for money that never arrived.
The responsible next step depends on what can be established about the first attempt. The record needs to distinguish permission, attempted execution, and the observed result.
When confirmation is missing, the outcome stays unresolved.Reconciliation examines the first attempt. A retry or corrective action needs authority appropriate to that response.
Field note 02Illustrative workflow
A $250 refund, four possible outcomes
An AI-assisted workflow proposes a $250 customer refund.
RequestRefund $250
AuthorityPermission established
EffectRefund observed
The ledger confirms the refund.
The authorized $250 refund appears in the downstream record. The operator can inspect the authorization, the attempt, and the observation that supports completion.
Development and evaluation
What you can
examine today
The first proposed evaluation concerns municipal records: permission-aware search with citations, followed by one conditional change to an internal review marker.
A deployment decision will need evidence from the matching implementation, including its behavior when requests change or confirmation is lost.
Review the technical evidence| Available material | Architecture and educational material, a historical harness inspection, and a technical evaluation brief. |
|---|---|
| Runtime evidence | The published review brief contains no current integrated runtime benchmark. The matching implementation and execution artifacts are still needed for that evaluation. |
| Test scope | Normal operation alongside denial, altered requests, revocation, duplicate attempts, interruption, and unavailable observation. |
| Before deployment | Agree the supported functions, measured results, limitations, operational owners, and recovery arrangements for the evaluated build. |