Level 2 · Technical detail
Technology — technical deep dive
For CTOs, CIOs, architects, engineers and researchers: how D-COS NEXUS is built, which principles it applies and its real maturity.
Architectural principles
One contract model
Every capability declares inputs, outputs, permissions and timeout: 80 contracts and 773 capabilities when every licence is present.
Fail-secure licensing
Without a valid Ed25519-signed licence only the base modules run; licensed modules refuse every call.
Read-only by default
Execute-class capabilities can be blocked globally (Zero-Trust read_only); effects with consequences need a signed human approval.
Honest states
Simulations are declared (decision D-24); hardware modules show whether a real device is connected.
Verifiable integrity
Signed registers for sources, executable and distribution, verified with public keys only.
One Root of Trust
One MASTER. One architecture. Thirty-six modules. One Root of Trust (M01).
The layers of the architecture
From the project's architecture map: every request goes through well-defined layers, from the user interface down to local, edge or cloud compute.
Components & platforms
Language & code
Python; final MASTER regression R14 with 4,086 tests passed and 0 failed (official V130 presentation).
Language models
Selectable provider: local Ollama (default, no credentials), or OpenAI, Gemini, Anthropic APIs and compatible endpoints. Credentials are read only from the environment, never stored in memory.
Memory
Three levels: episodic (with Chronos), semantic (vector store and knowledge graph) and autobiographical.
Console
Local web console (127.0.0.1) with isolated widgets, no external resources and session tokens; on a LAN only over HTTPS.
Platforms
Windows x64 (target platform): a single executable, dcos.exe. Command Center and console in six languages (Italian, English, Spanish, German, French, Arabic right-to-left).
Engine multilingualism
Deterministic detection of the request language (13 languages verified in tests) and replies in the user's language.
How status is shown
| A | Verified |
|---|---|
| B | Implemented |
| C | Partial |
| D | Planned |
| E | Not verifiable |
| F | Not implemented |
Evidence categories of the official documentation. Status of the 36 modules: 22 implemented and 14 partially implemented. Each module states its nature: base, real, hardware with simulated driver or declared simulation (D-24).
Documented checks
- Final MASTER regression R14: 4,086 tests passed, 0 failed, 16 skipped.
- Cross-validation of the 36 modules: 36/36 modules, 283 checks OK, 0 failed.
- Package acceptance test: 24/24 on the extracted archive; real-licence acceptance test 15/15.
- Release integrity: source register, signed executable and distribution manifest VALID; SBOM of 122 components, 0 known vulnerabilities (OSV).
- Independent external validation (Gate H): not yet carried out.
Technical roadmap
The direction comes from the status register and the engineering roadmap. None of the items below is an operational feature today.
Hardware custody of the keys
Import the current signing key into an Ed25519 device, then move the executable and licence keys to hardware.
Crypto Kernel everywhere
Migrate the P2P/mesh stack and the local TLS material to the M01 Crypto Kernel.
Independent validation
External validation (Gate H) and tests with real devices.
Let's talk about your project
Tell us about your context: we will reply with the relevant information and, where useful, with a proposal.