What the local decision establishes.
Authenticating a source is one input. Acceptance also depends on the requested operation, the intended asset, the applicable authority and the evidence available at the time of the decision.
The design principle is that loss of connectivity or supporting evidence cannot itself create permission. An action is accepted only within the authority that the local system can establish under its configured conditions.
Evaluate action, asset, authority and validity
Action-bound authority
Evaluate permission against the requested action, its target and its validity conditions.
Controlled degradation
Keep accepted actions within the authority that can still be established. Weaker connectivity or evidence must not create additional permission.
Local operational control
Design around the adopter’s operational authority, with no runtime dependency on D-Code infrastructure in the sovereign offline configuration.
A defined responsibility within the platform.
The proposed acceptance boundary sits between command inputs and the target platform’s execution path. The integration scope must identify all relevant paths through which controlled commands can reach the affected operation.
The platform retains its stabilisation, navigation, safety interlocks and pre-authorised contingency functions. Refusing a command is not an instruction to shut these functions down.
A sovereign offline configuration is designed without a runtime dependency on D-Code servers. Trust provisioning, time confidence, persistent state, evidence freshness and reconnection behaviour must be specified for the target platform.
Offline limits are explicit: a disconnected platform cannot immediately learn about a new revocation issued elsewhere. Validity and contingency policies must account for that information limit.
Evidence tied to its actual scope.
The available package documents architecture and acceptance requirements and includes selected synthetic reference-model checks of authority, replay and recovery conditions.
Model results are conditional on their stated assumptions, including trusted, persistent and non-forking state continuity. They are not flight trials, hardware security results or product certification.
An adopting platform needs its own evaluation of authorised-command availability, refused commands, restart and rollback behaviour, clock conditions, duplicate effects, bypass paths and recovery. Required timing and qualification criteria are agreed for that platform.
| Evaluation focus | What must be established |
|---|---|
| Permitted commands | Legitimate actions within the configured authority remain available under the stated conditions. |
| Out-of-scope commands | An expired, mis-targeted or unauthorised request does not enter the controlled execution path. |
| Replay and recovery | Repeated delivery, restart or rollback does not create an unauthorised duplicate effect. |
| Platform integration | Safety responsibilities, bypass paths, time and state assumptions are tested on the target configuration. |
A scoped IP package for adoption.
The commercial scope may include agreed evaluation or implementation rights, acceptance requirements, reviewable evidence and integration support. The licence identifies the applicable rights, deliverables and treatment of improvements.
Public materials describe the design intent and evaluation boundary. Unpublished claim detail, implementation know-how and other controlled technical materials are handled only within the approved disclosure scope.
Discuss licensingOriginal IP and technical foundations
AEGIS brings original IP together with insights from established research and publicly disclosed patent literature. We revisit useful ideas, including those disclosed in patents whose terms have ended, and assess them against the needs of today’s distributed and autonomous systems.
The architectural value lies in how authority, evidence and local state work together at the point of command acceptance. Our development process selects the useful elements, revisits their assumptions and defines how they should behave as a coherent system.
Public overview of our IP design areas
Bounded command acceptance
Relate an action to its intended target, permitted scope and validity conditions before it is accepted locally.
Privacy-aware authenticity
Design the confirmation of required identity or qualification attributes separately from the disclosure of unnecessary personal information.
Physical and digital evidence
Relate an object, the evidence presented and the requested action so that the evidence is evaluated in its intended context.
Distributed and offline operation
Address the consistency of commands, records and recovery conditions across multiple nodes and interrupted connections.
Licensing terms define the relevant original IP, know-how and integration scope. The status of third-party rights is assessed for the intended jurisdiction and implementation.