Home/Platform
Platform · the shared stackFour capabilities · one stack

Ekur — one stack beneath everything we build.

Determinism where it matters. Reasoning where it helps. Declaration where it scales.

Every Enkidu system runs on Ekur, a shared technology stack of four capabilities: Anshar for zoning and observability, Kittu for trust assurance, Nusku for fleet control, and Shedu for cryptography.

01 Anshar Zoning & observability Explore ↓ 02 Kittu Trust assurance Explore ↓ 03 Nusku Fleet control Explore ↓ 04 Shedu Cryptography Explore ↓
What we deliver

A governed platform — not a box and a model

Move the intelligence to the data. Governance is built in, not bolted on: zones bound what each component may do, and every crossing is brokered and evidenced at run time.

01

Deployable edge nodes

Ruggedised, self-contained units — compute, local model serving, sensor ingestion, and the trust harness in one enclosure — sized in tiers.

02

Mesh & reachback fabric

Neighbouring nodes exchange observations peer-to-peer over a self-healing mesh, so the picture survives the loss of any node or link.

03

Adaptive sensor ingestion

One common pipeline connects to the feeds your environment already has, through versioned, signed connectors. Sources are authenticated on arrival, normalised, and tagged.

04

Explainable, actionable outputs

Every indicator an operator sees carries what was detected, which sources contributed, and a confidence score computed from a signed, hash-linked chain of custody.

One pattern, four proving grounds

Defence

Distributed intelligence-fusion at the tactical edge — from dismounted teams to autonomous platforms, surviving network loss and reconciling upward.

Urban

Ambient urban-sensing fabrics for utilities, transport, environmental and emergency agencies — with a civilian privacy framework enforced at every share.

Medical

Hospital-connected smart health units — clinical-grade sensing, real-time AI triage flags, and live telehealth at the point of need, escalation designed in.

Legal

Evidence-handling and analysis environments where chain of custody, provenance, and reproducibility are not features but requirements.

The Ekur stack shown as five horizontal assemblies — sector-specific implementations built on the stack, Kittu trust assurance with a nine-stage ingestion-to-inference pipeline over a tamper-evident chain of custody, Anshar zoning architecture governing continuums across shared edge devices, Shedu quantum-ready cryptography, and Nusku fleet control distributing to edge AI devices.
Fig. — Ekur: the four capabilities
Long description

Ekur, the shared technology stack, holds four capabilities. Anshar, zoning and observability: bounds where work happens and watches everything that does. Kittu, trust assurance: models propose; deterministic code or humans commit. Nusku, fleet control: declares centrally, reconciles locally — and never touches the data. Shedu, cryptography: built so changing cryptography is routine, not a crisis.

01

Anshar

Zoning & observability

Zoning in for business success. Every operation decomposed into bounded, governed zones with explicit entry and exit conditions — so handoffs become contracts, failures become measurable, and improvement becomes systematic.

Overview

What you believe is happening vs. what is

The core dysfunction in most organisations is the gap between documented intent and measurable reality — and when things go wrong, no way to tell whether the failure was policy, operations, reporting, or structure. Anshar closes that gap by treating the boundary conditions between units of work — the points where responsibility is handed off — as the primary design objects.

A zone is a bounded operational space with one goal and two boundary conditions. The exit condition of one zone becomes the entry stake of the next, forming a chain of contractual handoffs; a message formally signals each crossing. You cannot manage what you cannot measure, and you cannot measure what you have not defined — Anshar makes your operations definable.

    The zone design test
  • "This zone begins when [entry condition]…
  • …ends when [exit condition]…
  • …with the goal of [zone goal]."
  • If you can't say it in one sentence under thirty words, refine the zone.
The model

Zones bound. Policies govern. Conops delivers. Reporting measures.

The foundation

Zones

A bounded operational space — physical, logical, or both — defined by functional coherence: one goal, explicit entry and exit conditions, and a defined error path.

"Is this permissible?"

Policies

Objective governance, kept pure of operational contamination. Given the facts, a well-formed policy returns a deterministic decision — so it can be tested, audited, and reported on independently.

"How do we do it?"

Conops

The day-to-day execution of service within a zone — the staff, procedures, tools, and workflows that enact policy decisions. A delivery channel is a medium; conops is the whole activity.

Closing the loop

Reporting

Nested levels of visibility — operational delivery, policy area, zone, and cross-zone program integrity — each aggregating the one below, from the front line up to the board.

The policy-purity principle: mixing policy with operations makes policy effectiveness unmeasurable and enforcement unpredictable. Keeping "what is permissible" separate from "how we do it" is the single most common — and most essential — discipline.

Design patterns

A small set of patterns scales to a whole enterprise

Continuums

A chain of zones forming one end-to-end process. Zones are the units of operational management; continuums the units of program management — dozens of zones, three or four continuums.

Subzones & overzones

Zone design is fractal — zones nest where complexity warrants it, and group where governance needs it. Add levels only when the benefit is clear; every level costs governance.

Error zones

Failures are first-class citizens with their own entry conditions, operations, and a structured route back. If your only error handling is "contact a supervisor," you have an undesigned zone.

Partner zones

External partners and regulators sit outside your model — so you design your side of the interface: what they owe you, what you pass them, and what happens when they fail.

02

Kittu

Trust assurance

The Trust Assurance Framework. Policy-based, evidence-backed, provenance-tracked trust in AI-augmented systems — asserted claim by claim at release, and verified step by step at run time.

Overview

Calibrated trust, not maximal trust

The goal is reliance matched to a system's actual, demonstrated trustworthiness — because over-reliance and under-reliance are both failures. A dependable system nobody can interpret invites under-reliance; a polished interface over an undependable system invites dangerous over-reliance. Kittu is built to deliver, and to demonstrate, both sides: objective dependability and the affordances that let you perceive it accurately.

Every trust claim is an assurance case — claim, argument, evidence — bound to exactly one policy with an explicit threshold and owner. A claim is satisfied only when the measured outcome meets the threshold and the evidence chain validates: every signature verifies, no hash link is broken, no evidence has expired. Never on a passing number alone.

    What it provides
  • Assurance cases: Claim → Argument → Evidence
  • Signed, hash-linked provenance — with expiry
  • A zero-trust harness verifying every live step
  • Capability earned through graduated trust zones
  • A live trust dossier an auditor can interrogate
What it assures

Nine components of trustworthiness

Each carries its own policy, claim, measurable outcomes, and evidence chain — and each maps to the NIST AI RMF trustworthiness characteristics, so the dossier cross-walks to recognised governance.

Competence & Reliability

Accurate, reliable performance across approved conditions — graceful at the edges.

Transparency & Explainability

Explanations measured for faithfulness, not just presence — at a level fit to the reader's role.

Calibrated Confidence

Stated confidence reflects actual likelihood of being correct — and signals where competence ends.

Predictability & Consistency

Stable under benign variation and across versions; changes detected and announced, never silent.

Accountability & Recourse

Decisions traceable end-to-end, human oversight on high stakes, a working appeal path.

Fairness & Bias Management

Measured on the worst-served group, not just the average — a strong aggregate can hide real harm.

Security & Robustness

Resists manipulation and adversarial input within a stated threat model; protects sensitive data.

Alignment with Intent

Pursues the goals stakeholders actually intend — an approved specification, not a harmful proxy.

Human Agency & Reliance

Humans keep control where it matters, and rely on the system exactly as much as warranted.

The recurring theme: confident wrongness is the most corrosive failure — it teaches users to over-rely and get burned, or to distrust the system entirely. Several components track confident errors separately.

At run time

The Trust Harness: never trust, always verify

The same claims, policies, and provenance move to inference time. The harness is a reference monitor for trust: nothing an agent produces — plans, messages, tool calls, outputs — is trusted by default. A checkpoint sits at every boundary, and delegated authority can never exceed the authority that delegated it.

Pre-flight · ingress

Classify & admit

Assigns the policy profile, checks input integrity and requester authority. Verdict: allow, sanitise, clarify, or refuse.

In-flight · per step

Broker every crossing

Validates each handoff and tool call against policy, enforces least privilege, bounds autonomy, and routes irreversible or externally-visible actions to a human hold.

Post-flight · egress

Prove before release

Checks the output is faithful to what actually happened, attaches calibrated confidence, screens for fairness and leakage, and attaches the provenance manifest.

Security and high-stakes checks fail closed — a timed-out evaluator blocks rather than allows. And no single probabilistic check is ever a sole gate: deterministic controls and least privilege bound the impact if any one check is wrong.

03

Nusku

Fleet control plane

The control plane for distributed intelligence — roll out models, monitor health, and respond to events across thousands of nodes, streaming only telemetry and signal upstream, never raw data. Structured by Anshar, governed by Kittu.

Overview

Declare centrally. Reconcile locally. Report by exception.

A distributed intelligence fabric succeeds or fails on a problem that is neither sensing nor inference: operating the fleet. Hundreds to thousands of edge nodes — carried by teams, mounted on vehicles, embedded in autonomous platforms, or bolted to poles — must be enrolled, configured, kept healthy, updated, and recovered when they fail, across intermittent, contested, and bandwidth-poor links. Doing this by hand does not scale past a handful of nodes; doing it with a conventional cloud device-management service violates the sovereignty, classification, and disconnection constraints these fabrics live under.

Nusku is Enkidu's answer: a sovereign, self-hosted control plane, and the third foundational framework of the stack. To the established premise — determinism where it matters, reasoning where it helps — Nusku adds its own corollary: declaration where it scales. Fleet state is declared, signed, and reconciled by pull, so a node that has been dark for a day converges to the same state as a node that never lost its link.

    The four capabilities
  • Fleet lifecycle at scale — zero-touch enrolment, node twins, pull reconciliation
  • Safe artifact distribution — signed, staged, health-gated, reversible
  • Fleet-scale observability — within a strict telemetry envelope
  • Autonomous event response — bounded remediation, human escalation
The components

One component at every tier

Nusku rides the same bearers as the data plane — with its own, strictly smaller traffic class. The hub is the unit of autonomy: a cluster cut off from the centre continues to reconcile, monitor, and remediate locally. And distribution follows the fabric: a 2 GB model update to a 40-node cluster costs the reachback link one transfer, not forty.

On every node

Nusku Agent

The small-footprint control-plane process: identity and enrolment, the reconciliation loop, artifact fetch and verification, fail-safe A/B install, local telemetry collection, and the local runbook executor.

On every hub

Nusku Warden

A local sub-control-plane: caches desired state and artifacts for its cluster, aggregates and downsamples telemetry, evaluates alert rules locally, coordinates rollout waves, and holds out-of-band recovery hooks — sustaining fleet operations through central-link loss.

At the centre

Nusku Core

The fleet registry and node twins, the signed desired-state store and artifact registry, the rollout orchestrator, the telemetry lake, the event engine, and the fleet operator console — deployable forward and central.

The node twin

Nusku's authoritative record of every managed node — identity, hardware tier, installed versions, bound policies, current health, desired state. The twin is what the fleet operator sees; the node is what exists in the field. Operators and the event engine reason over twins, never ad-hoc queries to the field.

The discipline

Six load-bearing invariants

They hold everywhere Nusku runs — because the control plane must be as disciplined as the fabric it operates.

01Control never carries data

No mission payload ever transits a Nusku channel — the telemetry schemas structurally cannot express mission content.

02State is declared and pulled

Desired state is signed at the centre; nodes reconcile by pull. Disconnection is a normal state, not a failure.

03Every artifact is signed and admitted

Nusku distributes; Kittu admits. A broken signature or provenance link stops installation at the node — regardless of what the centre ordered.

04Updates are fail-safe by construction

Every mutable install uses an A/B mechanism with automatic rollback — a failed update degrades to the previous working state, never to a bricked node.

05Remediation is bounded

Automated responses come from a signed runbook with explicit blast-radius limits. Anything outside it escalates to a human.

06The control plane is itself governed

Agent, Warden, and Core are agents under Kittu — trust zones, deny-by-default policy, every action in the chain of custody. The operator of the fleet is as accountable as the fleet.

Canada as the sovereign envelope: the territory where the data stays, the compute that runs inside it, and a perimeter that holds when the link to anywhere else does not.

04

Shedu

Cryptography

The quantum-resistant cryptographic layer of the Enkidu stack — hybrid post-quantum key establishment, quantum-resistant signatures, and fleet-wide crypto-agility. Enforced by Kittu, operated by Nusku.

The threat

Not a future problem. A present recording problem.

Every promise the Enkidu stack makes rests, in the end, on cryptography: Kittu's chain of custody is signatures, Nusku's artifact admission is signatures, every mesh link and reachback spoke is a key exchange. Against a cryptanalytically relevant quantum computer, today's public-key primitives break outright — and the harvest now, decrypt later attack means traffic recorded off a link today can be read retroactively the day such a machine exists. For a fabric carrying Protected B data with multi-decade sensitivity, the adversary needs no quantum computer now — only patience and storage.

The urgency is asymmetric: a signature forged in the future does not falsify the past, but a key exchange broken in the future retroactively exposes everything it protected. That is why Shedu's first wave is hybrid key establishment on links — and why the mandate horizon is not the quantum computer's arrival date, but the recording adversary's patience, subtracted from your data's lifetime.

    What it provides
  • Hybrid post-quantum key establishment on every link
  • Quantum-resistant signatures on every artifact & custody record
  • A hash-based-signed boot chain — the root of the argument
  • Crypto-agility as a fleet operation, not a rebuild
  • Compliance evidence generated from the fleet itself
The suite

One primary, one reserve — per function

Finalised NIST standards, deployed in hybrid constructions, with a designated backup on different mathematics behind every primary — so a cryptanalytic surprise is a policy flip, not a crisis program.

Function
Primary
Reserve
Key establishment
Hybrid X25519 + ML-KEM-768
ML-KEM-1024 at the defence ceiling
HQC — code-based, non-lattice
Signatures — custody, telemetry, verdicts
ML-DSA-65
ML-DSA-87 at the defence ceiling
SLH-DSA — hash-based
Signatures — firmware & boot chain
LMS (SHA-256) · XMSS
Verify-only builds on constrained nodes
Symmetric & hashing
AES-256-GCM · SHA-384/512 · SHA-3
Sized, not replaced — Grover answered by key size
Certificates / PKI
ML-DSA chains · hybrid in transition
Classical chains tunnelled until withdrawn

Profiles: the standard profile follows NIST Level 3 and Cyber Centre guidance for Protected B; the defence ceiling follows CNSA 2.0. FN-DSA (Falcon) is tracked for the most bandwidth-starved links once FIPS 206 finalises. And no algorithm outside the NIST process appears at all.

The layer architecture

Four binding points, zero new components

Shedu is a substitution of cryptographic substance, not an addition of moving parts. It changes what every existing handshake, signature, and boot check is made of.

Links

Every mesh link, reachback spoke, and control channel: TLS/DTLS 1.3 with hybrid X25519+ML-KEM groups, hybrid SSH for administration. The recording adversary gains nothing.

Identity

Node, hub, and operator certificates move to ML-DSA chains — hybrid during transition so a fleet mid-migration interoperates without downgrade ambiguity. Hardware-rooted keys where the tier supports them.

Integrity

Custody records, telemetry, and every registry artifact ML-DSA-signed; base-system artifacts dual-signed with LMS. Verification runs at the last trust boundary before use — a compromised cache can deliver nothing a node will accept.

Boot

A quantum-resistant fabric booted by a quantum-forgeable loader is a contradiction. The boot chain is LMS/XMSS-signed — the slot that fails Shedu verification is the slot that never boots.

Enkidu

Bring Enkidu to your edge

Book a technical walkthrough and see inference and defence running on your own hardware.