Universal Quality Development Harness
The platform's core engine. Nine phases. Self-mode and target-mode. Any codebase.
UQDH is the quality engine at the heart of CODITECT per ADR-320. It runs in two modes: self-mode (CODITECT applies the harness to itself for continuous self-improvement) and target-mode (CODITECT applies the harness to any customer codebase). The harness is parameterised - it discovers the target system's characteristics and generates a tailored quality plan. No hardcoding for any specific stack.
"We and every other software company in the world are outstripping our ability to test what we're building."
Why now: the velocity of agentic coding has decoupled from the velocity of testing, auditing, and validation - the knowledge and proof that AI agents did what they were tasked to perform, i.e. testing, in this case. An AI agent can produce more code in a day than a team used to write in a sprint. The test, audit, and compliance layers did not get faster at the same rate. The gap is structural and widens with every model release.
Three deficiencies - in every company today - that no software addresses:
- determining which tests need to run for a particular release
- checking whether they ran
- recording the outcome
Mark Walker, nue.io - meeting transcript [00:46:36]
UQDH is the engine that does all three across any target. Every phase carries inputs, outputs, and standards mappings; every run produces evidence in the audit trail.
The 9-phase harness loop (ADR-320)
The two modes
SELF CODITECT applies the harness to itself. The platform runs continuously against its own codebase, surfacing quality gaps, regressions, drift, and standards violations in its own delivery pipeline. The platform's audit trail is itself a UQDH OBSERVE output.
TARGET CODITECT applies the harness to any customer codebase. The DISCOVER phase reads the target's characteristics (language, framework, architecture, infrastructure) and generates a stack-tailored plan. No assumption about the customer's tech stack; no hard-coded paths for any specific framework.
Phases 1-5: understand the target, decide what to do
| Phase | Input | Output | Key actions | Standards mapped |
|---|---|---|---|---|
| 1. DISCOVER | Target system path, repo URL, or cloud endpoint | system-profile.json | Treesitter AST language detection, framework identification, architecture pattern detection, test/CI/database discovery, dependency graph, security scan, regulatory surface detection, documentation inventory | ISO/IEC 25010 §4.2, IEC 62304 §5.1.1 |
| 2. ANALYZE | system-profile.json | quality-assessment.json | Map system to applicable regulatory frameworks, score current state per framework, identify quality gaps, calculate technical debt, blast-radius risk, benchmark against DORA metrics, generate compliance gap matrix | ISO/IEC 42001 §6.1, NIST AI RMF (GOVERN, MAP) |
| 3. PLAN | quality-assessment.json | remediation-plan.json | 12-dimension critical-path scoring, ≤20-task sprint groups, effort estimates, sprint dependency graph, autonomy level per sprint (L1-L4), rollback plan per sprint | ISO/IEC 5338 §6.2, CMMI GP 2.2 |
| 4. SPECIFY | remediation-plan.json | Per-sprint specifications with acceptance criteria | Agent-executable system prompts, test criteria, deploy gates, traceability matrix (task → requirement → standard), Given/When/Then acceptance criteria, rollback procedures | IEC 62304 §5.2, ISO 13485 §7.3.3 |
| 5. RESEARCH | Sprint specifications + tech context | Implementation guidance with evidence-based recommendations | Search best practices for detected stack, dependency CVE search, framework-specific patterns, relevant ADRs, domain regulatory guidance | NIST AI RMF (MAP), ISO/IEC 42001 §7.2 |
Phases 6-9: execute, fix, ship, learn
| Phase | Input | Output | Key actions | Standards mapped |
|---|---|---|---|---|
| 6. IMPLEMENT | Sprint spec + research guidance | Code changes, config updates, documentation | Execute sprint system prompt (agent or human), apply STD-IMPLEMENTATION-LIFECYCLE, syntax/compile checks per change, mark tasks complete, generate diffs and commit hashes as evidence | IEC 62304 §5.5, ISO 13485 §7.3.4 |
| 7. REMEDIATE | Test or quality-gate failures | Fixed code, updated tests, root-cause analysis | Parse error output, trace root cause, minimal fix only, re-run failing + regression suite. After 3 iterations: escalate with blocking note. Root-cause analysis per failure for post-sprint review | ISO 13485 §8.5.2, ITIL Incident Management |
| 8. DEPLOY | Tested, reviewed code changes | Production deployment with validation | Pre-deploy gate checklist, platform-appropriate deploy, post-deploy smoke tests, 15-minute SLO-watch with auto-rollback, ITIL change record, CMDB update | ITIL Change Enablement, ISO 20000 §8.5.1, SOC 2 CC8.1 |
| 9. OBSERVE | Production metrics, quality data, sprint outcomes | Quality report + feedback into next iteration | DORA metrics (deploy frequency, lead time, MTTR, change failure rate), sprint velocity and accuracy, quality trends, process-improvement candidates, feedback to Phase 2, compliance evidence artifacts, dashboard update | ISO/IEC 42001 §9.1, NIST AI RMF (MEASURE), CMMI GG 3 |
Universal applicability - how DISCOVER adapts the harness
Phase 1 reads the target codebase and generates a stack-specific quality plan in subsequent phases. The same harness produces different gates depending on what it finds:
| Detected stack | Harness adaptation |
|---|---|
| Python / Django | pytest gates, ast.parse checks, Django migration safety |
| TypeScript / React | tsc --noEmit, npm run build, bundle-size gates |
| Rust | cargo test, cargo clippy, MSRV enforcement |
| Go | go test, go vet, golangci-lint gates |
| Java / Spring | JUnit, Checkstyle, SpotBugs gates |
| NestJS / Node | jest, eslint, Prisma migration gates |
| Mobile (Swift / Kotlin) | XCTest / JUnit, screenshot testing gates |
| Infrastructure (Terraform) | tflint, terraform validate, plan review gates |
| Documentation (Markdown) | markdownlint, link verification, frontmatter validation |
| Monorepo | Per-package gates, affected-package detection |
| Microservices | Contract testing, service-mesh health, distributed tracing |
| Database | Migration safety, schema-drift detection, data-integrity checks |
Why UQDH closes Mark's three deficiencies
Absence 1 - which tests must run. Phases 1-4 (DISCOVER, ANALYZE, PLAN, SPECIFY) generate per-change test selection from the live system profile, the gap analysis, and the SPECIFY traceability matrix that links every task to a requirement and a standard.
Absence 2 - that they ran. Phases 6-7 (IMPLEMENT, REMEDIATE) execute the planned tests, capture pass/fail and root-cause for each. Phase 8 (DEPLOY) gates production on pre-deploy and post-deploy verification.
Absence 3 - recording the outcome. Phase 9 (OBSERVE) collects DORA metrics, sprint accuracy, quality trends; the audit trail of every prior phase is the recorded outcome the regulator queries.
Standards covered in one engine
UQDH integrates ITIL, ISO, IEEE, and NIST controls into a single quality engine. Every phase is mapped to specific clauses (see the phase tables above). The standards are not bolted on; they are the gates and outputs of the loop.
- ISO/IEC 25010 (software quality model) - DISCOVER, ANALYZE
- ISO/IEC 5338 (software lifecycle processes) - PLAN
- ISO/IEC 42001 (AI management system) - ANALYZE, RESEARCH, OBSERVE
- NIST AI RMF (GOVERN, MAP, MEASURE, MANAGE) - ANALYZE, RESEARCH, OBSERVE
- IEC 62304 (medical software lifecycle) - DISCOVER, SPECIFY, IMPLEMENT
- ISO 13485 (medical device QMS) - SPECIFY, IMPLEMENT, REMEDIATE
- ITIL Change Enablement and Incident Management - DEPLOY, REMEDIATE
- ISO 20000 (IT service management) - DEPLOY
- SOC 2 CC8.1 (change management) - DEPLOY
- CMMI GP 2.2, GG 3 (process discipline) - PLAN, OBSERVE
The mapping is recorded in CODITECT's Research Foundations bibliography for every clause cited.
UQDH and the rest of the platform
UQDH is the central engine; every other surface on this site is one expression of it.
- QMS Process - the user-visible name for phases 1-9 applied to a single change.
- Unit Tests, Integration Tests, VTR + Playwright - the gates SPECIFY produces and IMPLEMENT executes.
- ITIL Issue Management - the REMEDIATE phase formalised as ITIL incident, problem, change, and configuration practices.
- Git Automation / CI-CD - phases 6-8 expressed as the per-commit pipeline.
- Iteration & Code Improvement - the OBSERVE → ANALYZE feedback edge of the loop.
- Compliance Coverage - the standards mapping above, expanded to every regulatory framework in scope.
- Context & Memory - the durable substrate that makes OBSERVE outputs queryable forever.
- Platform & Harness - the foundation-model-agnostic execution layer the engine runs on top of.