One Canonical Engineering Reality. Many governed ways to use it.

Capability depth and workspace are orthogonal.

L1–L5 answer how deeply NCT can understand and govern engineering reality. W1–W3 answer where a person works. A deep L5 engine can still return a simple result to a developer in W1.

Six public capability surfaces. One reality underneath.

See the control system, not a pitch-deck reconstruction.

The website uses current NCT product surfaces to explain how project reality, AI participation, health, evidence and engineering context are governed.

See the control system against a real engineering problem.

NCT is being built as infrastructure, not a demo narrative. The private review is designed around real project reality, governance, evidence and recovery.

Your responsibility changes. Your product does not have to.

NCT can contract to one person or expand across a team. The workspace is assigned by real responsibility, not by a hard-coded title. Whether you build alone or lead an organization, the same Canonical Engineering Reality can project the work surface you actually need.

• Individual Developer (W1 · L1–L3 commonly surfaced) — Build, test, inspect Git, work with or without AI, preserve context and evidence without carrying organizational overhead. Daily build, test, Git, AI-assisted development, context and evidence
• Tech Lead (W1 + W2 · L1–L4 commonly consumed) — Stay hands-on while seeing team execution, validation, evidence, quality, health and engineering gaps. Hands-on delivery + validation, team execution, quality and evidence
• Principal Engineer (W1 + W3 · L1–L5 selectively consumed) — Continue building while working deeply with architecture, relationships, governance and system-level engineering reality. Implementation + architecture, relationships, system constraints and deep engineering
• Engineering Manager / Director (W2 + W3 · L2–L5 commonly consumed) — Manage execution quality and engineering direction without being forced into the daily coding surface. Execution quality, health, risk, validation, team direction and governance
• Enterprise Architect (W3 · L3–L5 commonly consumed) — Focus on architecture, boundaries, relationships, history, governance and cross-system evolution. Architecture, boundaries, relationships, history, governance and evolution
• CTO / CIO (W2 + W3 · L3–L5 commonly consumed) — See delivery reality, risk, evidence, organizational governance and long-term engineering direction in the same system. Delivery reality, organizational risk, evidence, governance and long-term direction
• Chief Architect (W1 + W2 + W3 · L1–L5 full-spectrum access when responsibility requires it) — When one person genuinely carries development, oversight and architecture responsibility, all three workspaces can coexist. Development, oversight, architecture and higher-order engineering reality in one system

Person → Small Team → Enterprise. One core, adaptive complexity, minimum necessary exposure.

One product. Three places to work — based on what you are actually responsible for.

W1–W3 are not job titles and they are not L-levels. They are first-class workspaces that let the same NCT core fit an individual developer, a team lead, a principal engineer, an engineering director, a CTO/CIO, or a Chief Architect without forcing everyone into the same interface.

• W1 Development Workspace Build safely The daily engineering home: Files, Code, AI Development, Git/Diff, Test, Terminal, Engineering Memory, current task, current context and high-frequency execution. Individual Developer · Senior Developer · Principal Engineer · hands-on leads · Files / Code · AI Development · Git / Diff · Build / Test · Terminal · Current Task · Engineering Memory
• W2 Development Oversight · Validation · Management See independently A real development oversight surface for validation, quality and team execution — Observatory, Evidence, Tests, Gap, Performance, Health, Calibration, Development Quality, Team Development, Execution Status and Resources. Tech Lead · Engineering Manager · Engineering Director · verification / quality leadership · Observatory · Evidence · Tests · Gap · Performance · Health · Team Development · Execution Status
• W3 Architecture · Governance · Higher-Order Intelligence Expand intelligence without expanding loss of control System-level architecture, governance, authority, engineering relationships, history/time, architecture evolution, cross-team reality and higher-order engineering intelligence. Enterprise Architect · Principal Engineer · CTO · CIO · Chief Architect · Architecture · Governance & Authority · Relationships · History / Time · Evolution · Cross-Team Reality · Decision / Evidence

14-day full trial

Full Entry · real project · bring your own AI account · no token resale

The six capability areas

• Project Reality — Observe before changing. Ground the project before mutation: project identity, files, code, Git state, requirements, health, known/unknown boundaries, current versus historical facts, and Observer state remain distinguishable.
• Controlled Development — Human intent opens the development boundary. Turn human intent into a governed engineering episode: requirement, current task, controlled write boundary, ChangeSet, build/test, recovery and evidence stay connected instead of becoming disconnected actions.
• Governed AI Participation — Connected is not active. Active is not authorized. Treat AI as a governed resource: provider identity, model, selected resource, active participant, role, context eligibility, permission, authority and Human Gate remain separate states that can be audited independently.
• RCA & Technical Debt — Trace failure into durable engineering knowledge. Carry failure forward as engineering knowledge: symptom, evidence, root cause, repair, recurrence, technical debt, trigger and architecture impact stay linked so repeated local fixes can reveal structural causes.
• Evidence & Acceptance — Proof is a first-class engineering object. Make proof durable: tests, raw outputs, version binding, evidence, validation status, independent acceptance and human adjudication form a traceable chain rather than a completion claim.
• Context Continuity — Engineering memory belongs to the project. Preserve engineering meaning across sessions, providers, machines and handoffs: requirements, decisions, superseded facts, context position, RCA, debt, evidence and recovery remain project-owned memory.

The surface stays simple. The system underneath gets deeper.

NCT does not add a new product every time the problem becomes harder. The same engineering reality gains more relationships, proof and memory.

• Project Reality — Know what exists before changing it. NCT starts from the current engineering state, not from an AI conversation. Project identity, files, code, Git reality, requirements, health, known/unknown boundaries and current-versus-historical facts remain distinguishable before any mutation begins. Reality before action · Current state before mutation · Known / Unknown stay explicit · Observer ≠ Development
• Engineering Relationships — See what a change is connected to. A file change is interpreted in context: architecture decisions, contracts, dependencies, boundaries, requirements, evidence and prior failures can remain connected through one engineering relationship fabric without creating a second source of truth. Change is never just a file · Object truth stays with its domain · Relationship carries provenance · Impact is not authority
• Failure → RCA → Debt — A green test is not the end of the story. A passing test can still hide the wrong cause. NCT keeps failure evidence, RCA, recurrence, technical debt, operational impact and repayment triggers connected so repeated local patches can surface an architecture-level problem instead of being forgotten. Failure becomes durable knowledge · Symptom ≠ root cause · Debt keeps operational meaning · Trigger ≠ execution authority
• Evidence & Authority — AI can propose. Reality must still be proven. NCT separates what an AI claims from what engineering reality can prove. Tests, raw results, version binding, evidence, permission, authority, Human Gate and acceptance remain distinct so a convincing answer cannot silently promote itself into project truth. AI self-report ≠ acceptance · AI self-report ≠ acceptance · Permission ≠ authority · Evidence remains traceable
• Continuity & Evolution — The session can end without the engineering thought state disappearing. Project memory survives the end of a task session. Decisions, superseded facts, RCA, debt, handoff position, recovery, evidence and outcomes remain project-owned history, while each new AI task receives only the minimum sufficient context it is authorized to use. The AI can forget. The project should not. · Project remembers · Task sessions can reset cleanly · Historical truth ≠ current truth