On this page
Routing
How existing-repo repair and new-build work choose different evidence disciplines.
Routing chooses the evidence discipline.
Existing work usually needs repair discipline; new or replacement work needs design discipline.
The route shapes planning and checks, but it does not grant permission to widen scope or mutate unowned files.
Existing-repo repair
Existing work uses the repair route (DMAIC):
- define the problem
- measure current state
- analyze cause
- improve
- control the result with checks.
New build or replacement
New or replacement work uses the design route (DMADV):
- define the goal
- measure constraints
- analyze options
- design
- verify.
Mixed work
Mixed work uses both routes in sequence: a DMAIC shell for the existing-repo repair, then DMADV for the new artifact.
Routing chooses discipline; it does not authorize mutation or replace audit gates.
Existing-repo intake
Default: when an existing repo is present, start as existing-repo repair unless the user explicitly asks for a new artifact or replacement.
For brownfield work, inspect:
- current behavior
- owner and source of truth
- failing or missing evidence
- repo cleanliness
- what must not be touched.
The first plan should explain the baseline before proposing edits.
New-build intake
For greenfield or replacement work, inspect constraints, acceptance criteria, integration boundaries, rollback expectations, and the evidence that will prove the new artifact works.
Intake checklist
| Checkpoint | Existing-repo repair | New or replacement work |
|---|---|---|
| Owner / source | Which current file, generator, test, or doc owns the behavior? | Where will the new artifact live, and what source will own updates? |
| Scope / non-scope | What must not change while repairing the defect? | What is intentionally out of bounds for the first version? |
| Acceptance criteria | Which failing or stale evidence must change? | Which new evidence proves the artifact works? |
| Rollback / defer | How can the change be reverted or deferred if checks fail? | How can the new artifact be removed or disabled safely? |
| Generated artifacts | Is the target generated, and what generator owns it? | Will the new artifact generate output, and how is that regenerated? |
| Sidecar status | Does Graphify meet every first-contact trigger, and is ActiveGraph checkpoint/mirror use authorized? | Which anti-trigger, stale signal, or authorization boundary routes to ordinary tools? |
Casual-build intake
Plain-language requests can still become governed runs.
The intake should avoid interrogation while making the work safe enough to execute.
- Restate the concrete repo outcome in ordinary language.
- Classify the route as existing-repair, new-design, or mixed.
- Ask up to four batched questions only when owner/source, scope, rollback, or evidence cannot be inferred from the repo.
- Write the bounded work record with acceptance criteria and non-scope.
- Dispatch only after preflight, or hand off honestly if the target is unsafe or impossible.
Canonical files before sidecars
Routing evidence belongs first in the run folder and live repo files.
Optional Graphify or ActiveGraph sidecars can help maintainers, but they cannot replace owner/source notes, phase criteria, or before/after checks.
For optional sidecar boundaries, see Optional tooling.
Source surfaces
skills/implementaudit/references/routing.md and README.md greenfield/brownfield routing.
Route decision table
| Work | Plain route | Formal route |
|---|---|---|
| Existing defect, stale docs, broken checker | Repair existing | DMAIC |
| New artifact, workflow, package surface | Design new | DMADV |
| New artifact inside existing repo | Inspect existing, then design new | Mixed |
| Small single-owner fix | Plan-do-check-act | PDCA |
Routing is not permission
Routing chooses discipline and evidence shape.
- Does not authorize mutation.
- Does not authorize scope expansion.
- Does not authorize commit, push, release, publication, or provenance.
- Does not authorize sidecar export.