Action-bound authority
Evaluate permission against the requested action, its target and its validity conditions.
EXECUTION-CONTROL IP FROM JAPAN
Autonomy needs an authority boundary.
AEGIS is an IP architecture for local command acceptance. It is designed to keep accepted commands within pre-authorised limits as connectivity and supporting evidence degrade.
Offered through D-Code for integration into autonomous systems, critical infrastructure and space platforms.
Developed in Japan. Licensed for integration.
01 / The IP
A defined boundary for permitted action.
A command can come from a legitimate source and still fall outside its permitted scope. AEGIS addresses the local decision: whether the available authority and evidence permit this action on this asset, under the applicable 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.
Integration must preserve the platform’s stabilisation, safety controls and pre-authorised contingency behaviour.
Explore the architectureHow we develop the IPOriginal IP.
Original IP.
Foundations re-engineered for today.
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.
Explore our approach to IP02 / Use casesOne authority boundary.
One authority boundary.
Three integration contexts.
Application scenarios for evaluation. Qualification is specific to the target platform.
UAV / Autonomous systems
UAV & Autonomous Systems
When a delayed command reaches an aircraft after connectivity returns, its permission must still be valid. Evaluate local acceptance, refusal and replay handling alongside the existing flight controller and autonomy stack.
Explore autonomous systems
Water / Energy / Remote assets
Critical Infrastructure
Remote commands must stay within the authority granted for each asset and operation. Evaluate this boundary at the local controller while preserving authorised local operation and established safety controls.
Explore infrastructure
Satellites / Ground / Onboard authority
Space Systems
Intermittent contact makes the validity of received commands and delegated actions critical. Evaluate local authority checks against the intended asset, activity and validity window.
Explore space systemsAI-generated conceptual imagery. The images do not depict AEGIS-equipped platforms or customer deployments.
03 / EvidenceDefined rules.
Defined rules.
Reviewable evidence.
The current technical package includes documented acceptance rules, integration requirements and reproducible reference-model checks.
Selected authority, replay and recovery conditions have been checked with synthetic inputs under explicit model assumptions. Trusted state continuity is assumed in the models. Hardware validation is a separate qualification step.
View the evaluation scope01
Architecture and acceptance rules
DocumentedThe decision boundary and integration responsibilities are defined.
02
Selected reference-model checks
Executed under stated assumptionsResults address selected model conditions, with their assumptions and limits.
03
Platform validation and qualification
To be agreed for the adopting platformHardware, restart behaviour, timing and operational qualification require target-specific evaluation.
The principle / 24 secondsConnectivity can change.
Connectivity can change.
Authority does not expand.
A short illustration of the acceptance boundary through connection loss and recovery.
Concept animation · illustrative behaviour · no audioDownload MP4 ↓
Read the video transcript
Connected: each command still needs valid authority. Degraded: weaker evidence grants no additional permission. Link lost: only actions within locally established authority may be accepted. Reconnected: arriving commands are checked again; recovery does not grant blanket permission. Existing platform safety controls remain responsible for stabilisation and pre-authorised contingencies. This is a conceptual illustration, not footage of a validated implementation.
04 / LicensingLicense the layer
License the layer
your platform needs.
Commercial engagement is through paid IP licensing. Licence fees cover agreed evaluation and implementation rights. The adopting partner funds platform-specific validation and integration under a defined scope and acceptance criteria.
Paid IP rights
The licence defines the permitted use, deliverables and evaluation or implementation rights.
Partner-funded integration
The adopting partner funds its platform evaluation, integration and qualification.
Retained ownership
Core IP ownership is retained. Operational authority remains with the adopter. Treatment of improvements is agreed in writing.
Engagements are subject to Japanese export-control review, which we complete before any technical disclosure.
Detailed technical discussions proceed under NDA and an agreed disclosure scope.
A message from the CEOCompany information
A foundation for trusted autonomy.
As technology becomes more capable, we need a clear understanding of what a system is authorised to do. I believe this is one of the foundations of trust in AI and autonomous systems.
That trust depends on more than fast decisions or reliable connectivity. It also depends on who authorised an action, what that authority covers and the conditions under which it remains valid. Those limits need to hold where action takes place.
At D-Code, we develop this philosophy through the AEGIS architecture. Its design goal is to keep accepted commands within pre-authorised limits as connectivity and supporting evidence degrade, preserving the operator’s authority at the point of execution.
We also look carefully at the technical knowledge accumulated in research and patent literature. By selecting useful foundations, revisiting their assumptions and connecting them with original IP, we aim to build an architecture that addresses present-day implementation needs.
We aim to bring this approach to autonomous platforms and robotics, critical infrastructure such as water and energy, and satellite and space systems. Each application must be shaped by its own operating conditions and safety requirements, with clear criteria that adopters can evaluate.
Our role is to develop original IP and a clear architectural foundation, then work with partners who can carry it into their platforms. Through scoped IP licensing and partner-funded integration, we aim to make technology developed in Japan useful in demanding environments around the world.
Hiroaki Katsumoto
CEO, D-Code Inc.
Architecture notes
The Architecture of Acceptance
Selected perspectives on command authority and autonomous systems.
Start a conversation
Where does the authority boundary matter to you?
Send a brief, non-confidential introduction: your organisation, the platform you are working with and the command-control problem you want to address.
Message Hiroaki on LinkedInOpens Hiroaki Katsumoto’s LinkedIn profile. A short introductory message is enough to start.