How it's built
The discipline behind the swarm
Learning Nemo's most distinctive characteristic is not any single feature — it's the disciplined process used to design, build, verify, and govern an unusually large agentic system, much of it built by AI coding agents under explicit guardrails.
Five pillars of program management
Architecture as a single source of truth
One canonical architecture document defines every module's purpose, inputs/outputs, bidirectional contracts, type classification, and mapped NVIDIA tool. Contract-integrity rules are enforced whenever any module entry changes — every declared dependency must be mirrored, every declared capability must actually be provided.
A repeatable delivery methodology
Every module follows Arch → Spec → Code → Review → Merge, each stage gated by the next. A 9-section implementation-ready spec mandates a feature-extraction table and an inputs/outputs mapping table, so features in the architecture never go missing from the code. Role-specific agent prompts codify each stage.
Checking the agents' own work
Explicit review-vs-edit modes, minimal-diff discipline, targeted-reading to preserve context, cross-module breadcrumbs, curated context packages, deterministic validators, and a living Lessons-Learned registry that escalates recurring defects into process fixes. No silent fallback — a quietly degraded path is a failure, not a pass.
Everything is documented
A numbered decisions log (past DEC-097), a versioned changelog (~v5.9.137), dated session and hardware-day summaries, tracked issues and RFCs, and root-cause analyses for significant failures. Nothing changes silently; features, decisions, defects, and fixes are all written down and cross-referenced.
Multi-tiered, gated testing
>85% per-file coverage enforced in CI, hundreds of unit and integration suites, and deep end-to-end 'journey' tests that trace value across 5–8 modules and were validated on real GPU hardware (a 14-journey dashboard suite passed 89/89 live). Mock-first development, then GPU-validated — no module is permanently deferred.
CI/CD by design
A small, purposeful set of gates
The delivery pipeline is built on GitHub Actions, with the mandated workflow: branch → implement → local checks → PR → CI green → merge. No direct pushes to main for code changes.
test.yml Runs the suite on every PR and enforces the >85% coverage gate.
profiling-gate.yml Deterministic baseline-vs-PR profiling; blocks performance regressions.
deploy.yml Build/release validation on merge, incl. image build + rollout gates.
enforce-contract-consistency.yml Verifies inter-module contracts stay bidirectionally consistent.
validate-third-party-configs.yml A hardware-day informational check for service configs.
CODEOWNERS + Git LFS Required review on critical modules; large artifacts tracked; import-policy checks.
The throughline
Nothing changes silently
Features, decisions, defects, and their fixes are all written down and cross-referenced — in a numbered decisions log, a versioned changelog, dated session and hardware-day summaries, tracked issues and RFCs, and root-cause analyses for significant failures. A green exit code alone is never treated as success.