Timeline & Next Steps | n.tasc Agentic Transformation

Master Schedule

Stages overlap because a boutique team cannot dedicate itself to one stage at a time

W1–2W3–4W5–6W7–8 W9–10W11–12W13–14

S0 — Foundation

W1–3

S1 — Knowledge Base

W2–5

S2 — Safety Net

W4–8

S3 — Pilot

W7–11

S4 — Measure & Refine

W10–12

S5 — Rollout

W11–14

S6 — Continuous

W13+

What each stage needs from the one before it

Stage	Weeks	The one thing that must come out	Gate to proceed
S0 Foundation	1–3	Signed baseline including the seven-band time split	Baseline agreed in writing by both sides
S1 Knowledge Base	2–5	Patterns file, domain glossary and module docs reviewed by their owners	Contradictions in the codebase resolved and written down
S2 Safety Net	4–8	Enforced CI gate, characterization coverage, golden datasets frozen	Suite green and gating. Agents replay-validated
S3 Pilot	7–11	One change end to end, one non-owner change, one restricted-zone change	Full metric set captured against the baseline
S4 Measure	10–12	Per-agent verdicts and a joint, documented rollout decision	Evidence supports scaling. A real gate
S5 Rollout	11–14	All modules onboarded. Internal maintainers trained	Runbooks handed over. Stewards named
S6 Continuous	13 on	Named duties with a cadence, owned entirely by you	—

Staffing Assumptions

Stated because the schedule depends on them, and we do not have your headcount yet

These are assumptions. Tell us where they are wrong.

The 14 weeks assume one pilot squad. If n.tasc is maintained by three people, the stages stretch and we would propose a leaner fleet in a different order. If it is twenty across several squads, Stage 5 parallelises and rollout compresses. The sequence holds either way. Only the duration changes.

Role	Assumed commitment	Heaviest weeks
Tech lead / architect	About half time across the programme	W1–5 (audit, patterns), W10–12 (verdicts)
Backend engineers (2)	About a quarter time to W6, then full pilot participation	W7–11
UI engineer (1)	About a quarter time, mostly in the pilot	W9–11
QA engineer (1)	About half time, rising through Stage 2	W4–11
Domain owner(s)	2–3 days per golden-dataset scenario family	W4–7 — the hardest commitment to protect
DBA	Occasional, for schema and migration review	W4–8
Product / BA	About a quarter time for spec review	W7–11
ConceptGood consultant	Embedded throughout	Full programme

What We Need in Week One

Nothing here needs a commitment beyond the engagement itself

Repository and pipeline access

Read access to the n.tasc codebase, plus sight of the current build configuration. Read-only is enough for all of Stage 0.

Delivery history

Last 20 completed changes and last six months of defects. This is where the baseline and the seven-band time split come from.

An hour with the module owners

The conventions and quirks that are not written down anywhere. Scans find structure. Only people know intent.

Named domain owners

The people who can say whether a business-critical figure is right. They own the restricted gate for the life of the programme.

Schema access

Schema only, never production data. Enough to inventory where business logic lives in the database.

A view on the client contracts

Does any of them constrain AI-assisted development or require disclosure? Better in week one than month four.

A candidate pilot module

Real client-requested work, outside the deepest restricted zone, crossing backend / React UI / database, with a steward who wants it to work.

Answers to the open questions

The Assumptions section lists what this plan assumes. Correcting those is the fastest way to sharpen the schedule and the fleet.

Where we start on day one

The baseline. Pulling the last 20 changes apart into the seven bands tells us which agents matter most for you rather than in general — and it is the number every later claim gets measured against.