Inside the engineering.
Trace how source code, models, agents, and policies connect across DevHeal systems. Explore execution models, implementation details, and validation methods.
From source to execution.
Follow the compilation pipeline, interface generation, local inference, and analytical model design.
NC language and runtime
Explore this component in the unified NC product family.
Read the NC language and runtime details →NC UI interface generation
Explore this component in the unified NC product family.
Read the NC UI interface generation details →NC AI local inference
Explore this component in the unified NC product family.
Read the NC AI local inference details →NeuralEdge analytical pipeline
NeuralEdge combines market data ingestion and caching with technical indicators, portfolio optimisation, risk calculations, and sentiment analysis. API endpoints expose analysis to connected applications.
The analysis pipeline tracks prediction outcomes to adjust model weights. Validate data coverage and model behaviour against the requirements of the target analytical workflow.
Nova model architecture
Transformer-based infrastructure intelligence with specialised diagnostic, routing, gating, confidence, and retrieval heads.
Explore the architecture →From intent to governed action.
Explore the execution loops, coordination mechanisms, memory, and feedback behind autonomous workflows.
SteadyState platform architecture
Evidence-linked investigation, specialist agents, policy-controlled action, and measured recovery.
Explore the architecture →HiveANT swarm coordination
Problem: production incidents require investigating, diagnosing and fixing failures faster than any one engineer can coordinate. Approach: Ant Colony Optimization and Artificial Bee Colony swarm algorithms coordinate many autonomous agents to investigate, diagnose, fix and learn from software failures. Technical scope: built on the NC engine, with coordination parameters configured for each environment. Limitations: best suited to environments with good observability data already in place; swarm coordination parameters need tuning per environment.
SwarmOps incident workflow
Problem: when a service breaks, root-causing it usually means paging someone and waiting. Approach: AI-powered incident investigation combining reinforcement learning, cognitive memory and RAG — pulls data, finds the root cause, proposes or applies a fix, and learns from the outcome. Architecture: single NC binary (~478KB), zero external dependencies. Limitations: automatic remediation should run in supervised mode until an organization has validated its recommendations in their own environment.
AgentOS execution model
AgentOS defines a shared execution foundation by extracting common runtime patterns from HiveANT and SwarmOps. The shared runtime design is derived from the existing product source.
Where AgentOS is heading is documented in Patent Family B's autonomous multi-agent orchestration claims — see Patents & IP — which describe the pheromone-graph reinforcement and digital-twin analysis already running inside HiveANT today.
Bound authority across software and hardware.
Review influence budgets, decision evidence, and isolation boundaries.
AGP influence governance
Problem: the industry has largely solved authentication for AI agents — proving which agent is acting. It has not solved influence governance — bounding how much any one input (a document, a tool result, a prior message) is allowed to shape a privileged action before that action commits.
Approach: every input-to-output influence is tracked as a signed "compute edge" with a per-input cap and an aggregate influence budget. A privileged action is refused before it commits if the budget is exceeded. Every decision produces a causal receipt committed to a hash-chained ledger that an auditor can verify completely offline.
Architecture: a C core (capsules, edges, ledger, authorization) plus a hardened HTTP gateway (TLS, rate limiting, audit) exposing a decision API, with a drop-in MCP middleware that gates tools/call in front of an existing MCP server — no agent rewrite required.
// adversarial influence-spreading benchmark per_input_cap_only attack_success 75.0% benign_blocked 0.0% + aggregate_influence_budget attack_success 0.0% // 4/4 blocked benign_blocked 0.0% // no false positives
Technical scope: a working prototype, internally benchmarked — 86 tests passing, with the core C authorization logic (20 of the 86) verified under AddressSanitizer and UndefinedBehaviorSanitizer; the remaining integration tests are functional but not yet run under sanitizers. Hardware attestation (TEE) backends are currently simulated, not hardware-verified. A patent application covering the governance protocol has been filed (Patent Family C) — see Patents & IP.
AgentOS Kernel isolation
A lower-level, separate research thread from the AgentOS runtime above: a bare-metal type-1 hypervisor that partitions CPUs and memory into hardware-isolated domains, so one agent's runtime can't read another's memory even if the software layer is compromised.
What's verified: it boots and auto-detects hardware inventory under emulated firmware (OVMF/QEMU), and two guest domains have been demonstrated running under distinct nested page tables, proven not to read each other's memory — across a 14-lane automated test matrix (9 hardware-configuration lanes plus 5 negative/failure-case lanes) for the 64-bit hypervisor build. What we're not claiming: this has not booted on physical hardware, and only AMD's virtualization extensions are exercised so far (no Intel VT-x path yet). The project's own internal readiness gate — a 104-check automated audit — currently reports a failed verdict, and its own documentation is explicit: this is "a real but minimal kernel, not a supported production platform."
Connect the development lifecycle.
Review coding tools, operational control planes, and workspace design.
NC-Code and NC-OS tooling
Explore the engineering projects behind our platform, including their implementation scope and technical limitations.
NC-Code
What it is: a bring-your-own-key AI coding and ML agent for terminal and desktop. Implementation: permission-gated tools, crash-safe encrypted undo for agent writes, and a working Proof Gate — a signed, digest-bound receipt naming exactly which checks ran against which bytes before a change is accepted. Technical scope: version 0.1.0, unreleased. The Proof Gate package is the first piece prepared for release; the CLI, daemon and desktop app are not yet published, packaging remains part of the engineering work.
NC-OS
What it is: an LLM-ops control plane — tracing, evaluation, prompt management, orchestration, datasets and monitoring, positioned as an alternative to assembling several separate LLM-ops tools. Implementation: a substantial, actively-developed core service with tenant-scoped isolation and a signed, hash-chained audit log. Audit design: tenant-scoped records use signed hash chaining. Technical scope: the core service is substantial; a "DevHeal AI OS" sub-project inside it is explicitly foundation-only (health/readiness endpoints), with workflow execution, agents, tools and RAG still to be built.
DevHeal Studio workspace design
Studio’s workspace design connects the components of an AI system — the agent, the tools it calls, the memory it reads and writes, the policies it must obey, and the trace of everything it did.
Design scope: the internal prototype and specification cover the intended capabilities below.
// what "engineering an AI system" means in Studio design // lay out agents, tools, memory, policy build // wire tools + connect data sources configure // memory scope + policy constraints run // execute against real or simulated input trace // inspect every step the agent took evaluate // score the run against production-readiness simulate // replay against scenario suites debug // step through a failed run deploy // ship the compiled system operate // watch it run in production heal // checkpoint, reconcile, recover
The list above describes the Studio workspace design.
Define behaviour across success and failure.
Explore scenario design, evaluation criteria, recovery patterns, and compilation contracts.
D-TwinVoke assurance architecture
Twinning enterprise context creates a safer place to assess autonomous actions before they reach live systems. D-TwinVoke combines a living system model, counterfactual simulation, invariant checks, and governed invocation in one assurance workflow.
Coming soon: D-TwinVoke is under development. The product page presents the intended capability and assurance workflow without claiming general availability.
D-AgentProving assurance pipeline
D-AgentProving evaluates complete agent runs rather than isolated model responses. Agents operate against simulated services while the assurance pipeline records decisions, tool calls, state changes, recovery behaviour, policy adherence, latency, and cost.
Demonstration: connect one agent workflow and review its simulated actions, failure handling, scorecard, and evidence receipt with the DevHeal team.
Compiler, Recovery Engine, and Edge Runtime
AI System Compiler
Problem: NC compiles a program; it does not yet compile a whole system of agents, tools, policies and memory as one unit. Approach: extend NC's compiler pipeline to validate cross-component contracts (tool schemas, memory access, policy constraints) at compile time instead of at runtime.
Recovery Engine
Problem: a failed step mid-workflow can leave a transaction half-complete. Approach: generalize the checkpoint/reconcile/compensate pattern HiveANT and SwarmOps already use for their own operations into a reusable engine any NC-built system can call. See the Heal philosophy.
Edge Runtime
Problem: NC AI already runs on a laptop CPU; running it on constrained edge/embedded hardware is a different set of tradeoffs. Approach: a stripped-down build of the NC AI runtime targeting edge devices. This section describes the target architecture.
DH-ADOM
A hierarchical operating model for agent-led engineering: clear domain ownership, bounded delegation and evidence-backed handoffs.
Explore the paper, diagrams and source →Podotl
Explore the GL-SSM architecture, telemetry fusion, contract checks, and workload-specific evaluations.
Podotl architecture →