the technical case
the technical case · hyper engineering, in architecture terms

The system you can actually trust in production.

Stochastic generation can’t go in your SDLC. Drift, hallucination, and an audit trail full of prompts aren’t answers your security review will accept.

nmux is a deterministic, locally-run pipeline of specialized agents, each gated by an enforceable contract. The outputs are reproducible, auditable, and SHA-256 verifiable. This page is the architectural case for adopting it.

↳ the trust budget
100% reproducible on re-run (sha-256 verified) 0 bytes leave your network (local-only execution) 8 default agents · swap or extend any (or define your own)
↳ single static binary · no telemetry · no vendor in your supply chain
§ 01 — the trust gap

What we can’t put in production. And what we can.

criterion chat-driven coding nmux pipeline
Reproducibility Same prompt, different output. No. Same spec → same pipeline. SHA-256 verifiable.
Auditability A chat log. Maybe. Every routing decision, every agent action, in your repo.
Code custody Pasted into someone else's context window. Local-only. Your code never leaves your network.
Standards enforcement A README and good intentions. ADRs + contracts as gates. The pipeline halts on violation.
Failure mode Silent drift. Discovered in review. Loud, traced, attributed to a specific phase.
Composability Re-prompt. Re-prompt. Re-prompt. Phases swap. Pipelines compose. Standards inherit.
see the full three-way comparison with enterprise AI platforms see the comparison table →
§ 02 — architecture

A pipeline. Not a prompt.

Five phases, five contracts. Or ten, or twenty. You decide. Your SDLC requirements dictate how things get built, every time all the time. The output of one is the verified input of the next. Nothing advances without passing its gate. Hyper engineering, by construction.

01
Intent
↳ structured spec from natural language
02
Plan
↳ ADRs, contracts, test plans
03
Iteration loop
↳ code generated, reviewed, refactored against plan
04
Verify
↳ gates · contracts · attestation
05
Feedback
↳ make your SDD learn from what it did
↳ each phase: contract-in, contract-out · halt-on-violation ↳ artifact bundle accumulates at every step

Got some pesky compliance gates that must be passed before code can be merged? Model them as a phase. Want to enforce a test-driven development workflow? Model it as a phase. Want to make sure every spec is reviewed by a senior engineer before implementation begins? Model it as a phase. Your process, your rules, encoded in the architecture of your pipeline.

§ 03 — the swarm

A specialist for every criterion. Run in parallel.

Single-shot review by a generalist model is the wrong shape for production code. nmux ships a default swarm — each agent owns one criterion, each is content-addressable, each emits a typed finding the gate can act on. Swap any for one of yours. Or define your own.

agent · 01
Spec Linter
ambiguity / completeness
↳ spec-lint-v3
agent · 02
ADR Reviewer
architectural fit
↳ adr-eval-v2
agent · 03
Contract Checker
interface preconditions
↳ ct-check-v4
agent · 04
Security Auditor
owasp / injection / authz
↳ sec-aud-v3
agent · 05
Type Verifier
static + flow analysis
↳ tyv-v2
agent · 06
Test Synthesizer
coverage of declared paths
↳ tsyn-v3
agent · 07
Style/Lint
house standards
↳ style-v1
agent · 08
Performance
complexity / hot path budget
↳ perf-v2
↳ swap any agent for one of yours · add your own · all agents content-addressable · finding format is typed JSON
§ 04 — what comes out

A bundle. Not a diff.

Every nmux run produces a content-addressable artifact tree. ADRs, contracts, implementation, tests, agent findings, audit trail, attestation.

nmux artifact bundle · run-9d4f2e ↳ merkle: ee01aa14…
/run-9d4f2e/
manifest.json 1.2K 9d4f…2ec1
/01_intent/
spec.md 4.8K f2c8…91ab
intent.json 0.6K 0a1b…77ed
/02_plan/
adr-007.md 2.1K 44ee…1102
contracts.ts 3.4K ab12…cd34
test-plan.md 2.9K 8800…ff21
/03_implement/
src/order.ts 6.2K 771a…ee0c
src/order.test.ts 4.1K dd92…44a1
/04_review/
▸ findings.json 8.7K 5c5c…22b9
audit-trail.log 12.4K ee01…aa14
/05_verify/
attestation.json 1.8K 99fe…3344
sbom.spdx 5.2K 1234…5678
↳ 17 artifacts · 54.6KB total · re-runnable indefinitely
findings.json · json
             1  {
 2    "phase": "review",
 3    "agents": 8,
 4    "blocking": 0,
 5    "advisory": [
 6      {
 7        "agent":     "performance",
 8        "severity":  "advisory",
 9        "location":  "src/order.ts:142",
10        "criterion": "hot-path budget",
11        "message":   "O(n²) on large carts; consider memoization",
12        "rule":      "perf.complexity.advisory"
13      },
14      { "agent": "style", "severity": "advisory", "count": 2 }
15    ],
16    "verdict": "pass-with-advisories"
17  }

          
↳ this bundle commits to your repo · attestation signed · re-runnable indefinitely Inspect one live →
↳ what this bundle gets you
A SOC2-ready audit answer, in your own repo ↳ no third-party retrieval Re-runnable in your CI, six months later ↳ hashes match · contract-bound Every routing decision attributed to a phase ↳ forensic by default Zero vendor in your supply chain ↳ single static binary
↳ inspect a real bundle on your repo Request a walkthrough
§ 05 — properties

Four properties. All non-negotiable.

01

Reproducible by construction

Same spec → same pipeline, same gates. Re-run six months from now and the process is identical. The non-determinism of LLMs is contained inside agent boundaries, not exposed to the SDLC.

↳ reproducibility · sha-256 verifiable
02

Local-only execution

Distributed as a single static binary. No telemetry, no calls home, no third-party SaaS in your supply chain. Code, prompts, and outputs all stay in your network — no asterisk.

↳ data isolation · airgap-compatible
03

Standards as enforced gates

ADRs, contracts, and house policies aren't aspirational README content — they're contracts the gate checks. The pipeline halts on violation.

↳ policy-as-code · halt-on-violation
04

Auditable every step

Every routing decision, every agent invocation, every finding — logged, hashed, attributed. You can answer 'why was this code generated' six months later. With evidence.

↳ soc2-friendly · forensic by default
§ 06 — integrations

Drops into the stack you have. No replatform.

vcs
GitHub / GitLab
PR-as-pipeline · status checks · review attestations
ci
GitHub Actions
first-class action · runs as a single binary
ci
CircleCI / Buildkite
shell out · zero-config · same artifact bundle
ide
VS Code / Cursor
inline pipeline runs · inspect any phase locally
ide
JetBrains
plugin · same protocol
policy
OPA / Conftest
your existing policies · enforced as gates
supply-chain
Sigstore / Cosign
attestations signed · SBOM in every bundle
obs
OpenTelemetry
every phase emits spans · in your collector
§ 06b — what your CTO will ask

The questions you’ll get in the architecture review.

We’ve sat through enough architecture reviews to know which questions come up. Here they are, with the short version of each answer.

q · 01

Why specialized agents instead of one capable model?

Single-model review drifts — the one that's strong at types is weak at perf; the one that catches injection misses ADR fit. Specialists are criterion-bound, content-addressable, and produce typed findings the gate can act on. Swap any. Define your own.

q · 02

What's the latency/cost of running 8+ agents in parallel?

Agents run in parallel by design — wall-clock is bounded by the slowest, not the sum. Inference cost scales with the compute you provision, not seat count. The model in the business case estimates the compute load for a typical 14-engineer team.

q · 03

How do agent failures cascade through the pipeline?

They don't. Each phase is contract-bound — halt-on-violation, not silently-degrade. Findings are typed and attributed to a specific agent. State persists across sessions, so failures resume from the last checkpoint, not from scratch.

q · 04

How does this play with our existing CI/CD?

It IS your CI/CD action. First-class GitHub Action, shell-out for CircleCI/Buildkite, IDE plugins for VS Code/Cursor/JetBrains. Same artifact bundle regardless of where you run it. See §06 above for the integration matrix.

§ 07 — next

Run the pipeline on your code.

30 minutes with one of our engineers. We’ll run a representative spec through the full pipeline, live, and hand you the artifact bundle that lands in your repo. Bring your own spec if you want.

↳ also reading? see the business case nmux © mmxxv · the exo-suit for your hyper engineering team