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.
Details
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
Cross-platform with official support for Windows 10/11, macOS and Linux (x64 and ARM64):
Details
a dedicated package for each system. Docker and Android (Termux) are also planned. Command Center and console in six languages.
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.
Cross-platform: Windows, macOS and Linux
D-COS NEXUS is a cross-platform ecosystem with official support for Windows, macOS and Linux. Its code, written in Python, handles the differences between operating systems, and an official build pipeline produces a dedicated package for each platform.
Windows 10/11 (x64)
Signed executable dcos.exe with the Python and Visual C++ runtimes included. Package acceptance test 24/24.
macOS (Apple Silicon and Intel)
Official packages for macOS ARM64 and x64 produced by the build pipeline. Laboratory testing and Apple notarisation still to be completed.
Linux (x64 and ARM64)
Official packages for Linux x64 and ARM64 and a systemd service for servers and mini-PCs. Laboratory testing still to be completed.
Docker · NAS · Raspberry Pi 4/5
Dockerfile and docker-compose for PCs, NAS, mini-PCs and Raspberry Pi 4/5.
Smartphones and tablets
HTTPS console usable from the browser of phones and tablets, already tried. Running on Android through Termux is set up.
Each PyInstaller build only runs on the system it was built for, so every platform has its own package.
Details
Some functions use Windows services: outside Windows the vault opens with the recovery passphrase (scrypt) instead of DPAPI, and automatic device detection (Plug and Play) is available on Windows only.
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.