Purpose. Shows what work streams can run in
parallel, what must gate on what, and where the hard serial points are.
Companion to RESPONSE.md.
1. Read this first — the shape of the problem
Three kinds of work in this programme:
- Platform floor — has to exist before most modules can be written (tenancy, RBAC lib, audit writer, BFF skeleton, seed loader). Partially parallelisable internally.
- Module work — highly parallelisable after the platform floor + Auth/AuthZ are in place.
- Cross-cutting passes — WCAG, load test, security review, operator docs. These run late, over whatever modules exist.
The single biggest scheduling fact: Auth + AuthZ + Tenancy
are on the critical path. Almost nothing else can ship until
the RBAC middleware is real. Every module calls
requiresPermission(resource, action) on every write. If
that middleware is a stub, every module ships on a fiction.
2. Pre‑work (before W0) — this is what "before" means
These must happen before engineering starts. Most are decisions, not code. Skipping any one of them delays W1 by at least one week.
2.1 Decisions (client + we jointly)
PRE-WORK GATE (must all close before kickoff)
[D1] Scope commit ──► Core-only | Core+Extended | Full17 (not recommended)
[D2] Stack sign-off ──► Go/TS/Mongo/Redis/MinIO (default) or Java alt
[D3] Answer G-1..G-10 ──► See RESPONSE.md §3.1
[D4] SME assigned ──► GRC/Compliance SME named, contracted
[D5] Design system ──► Exists? Use shadcn/ui? Build fresh?
[D6] Air-gapped target ──► W8 must-have or W12 hardening? (G-7)
[D7] LLM provider ──► For §3.7 AI enrichment, or feature-flag off
[D8] Reference load ──► Orgs × users × concurrent scans for NFRs
[D9] Deployment target ──► Compose (demo) or k8s (prod) for RC1
[D10] Sandbox access ──► 1 sandbox tenant per integration provider
(AWS, GCP, Azure, GitHub, GitLab, Entra,
Google Workspace, Okta) — needed by W5All 10 can be negotiated in parallel across 1–2 weeks of client conversations. This is the pre-W0 window.
2.2 Artefact production (our side, in parallel with client decisions)
[A1] Reference designs for summary-only modules (§3.2-§3.17)
──► Tech Lead drafts thin designs analogous to AuthZ doc
──► Per module: data model, state machine, BFF routes, permissions
──► ~2 days × 13 modules = 5 eng-weeks (parallelisable across 2-3 leads)
[A2] Seed-data contracts
──► Schemas for: framework, atomic control, mapping, vendor library
entry, policy template, CSPM check, SCM check
──► 1 week (tech lead + SME)
[A3] Threat model draft (Auth, AuthZ, Tenant isolation)
──► 1 week (security-minded senior)
[A4] Repo layout + module boundaries spec
──► Monorepo vs polyrepo, package structure, internal APIs
──► 3 days (tech lead)
[A5] Connector framework contract
──► gRPC / HTTP, credential handling, scan-run model, retry/backoff
──► 3 days (tech lead)
[A6] Observability catalog (C-11)
──► Metric names, trace-span names, log schema
──► 3 days (platform eng)
[A7] Test strategy
──► Unit / integration / contract / E2E / load — tooling + coverage bar
──► 2 days (QA lead)Total pre-W0 calendar time: ~2 weeks, running in parallel with client decisions.
3. High‑level programme map
┌───────────────────────────────────────────┐
│ PRE-W0 (2 weeks) │
│ Decisions D1..D10 │ Artefacts A1..A7 │
└────────────────────┬──────────────────────┘
│ GATE: all cleared
▼
┌─────────────────────────────────────────────────────────────────────────┐
│ W1–W3 FOUNDATION WAVE │
│ │
│ ┌─────────────────────┐ ┌─────────────────────┐ ┌────────────────┐ │
│ │ PLATFORM FLOOR │ │ AUTH + AUTHZ │ │ SEED DATA │ │
│ │ (5 streams parallel)│ │ (2 streams parallel)│ │ (SME, parallel)│ │
│ └─────────────────────┘ └─────────────────────┘ └────────────────┘ │
│ │
│ ┌───────────────────────────────────────┐ │
│ │ COMPLIANCE ENGINE CORE (after W2) │ │
│ │ Control Library • Framework Scoring │ │
│ │ Evidence Engine • Audit Log │ │
│ └───────────────────────────────────────┘ │
└──────────────────────────┬──────────────────────────────────────────────┘
│ GATE: RBAC middleware live,
│ seed loader working,
│ audit log writing
▼
┌─────────────────────────────────────────────────────────────────────────┐
│ W4–W6 MODULE WAVE │
│ (highly parallel once platform + compliance core are up) │
│ │
│ [Team A] Vendor Management (#6) ─── detailed spec, 5.5 ew │
│ [Team B] Policy / Document Control (#7) ─── detailed spec, 6 ew │
│ [Team C] Risk (#5) + Integrations (#17) + Dashboard (#16) │
│ [Team D] CSPM #9 (if Extended) / else harden compliance engine │
│ │
│ Frontend teams pair with backend teams (not separate phase) │
└──────────────────────────┬──────────────────────────────────────────────┘
│ GATE: Core modules functional,
│ auto-evidence emitting
▼
┌─────────────────────────────────────────────────────────────────────────┐
│ W7–W8 HARDEN + RELEASE │
│ │
│ [Parallel] WCAG AA pass │ Load/perf test (REQ-PERF-1..4) │
│ Security review│ Pen-test remediation │
│ Operator docs │ Backup/restore dry run │
│ Helm hardening │ UAT prep │
│ │
│ ─── W8: Release Candidate + client UAT + sign-off ─── │
└─────────────────────────────────────────────────────────────────────────┘
(Extended, optional)
│
▼
┌─────────────────────────────────────────────────────────────────────────┐
│ W9–W12 v1.0-EXTENDED (highly parallel) │
│ CSPM (AWS/GCP/Azure) │ SCM (GitHub/GitLab) │ Supply Chain │ VA │
│ Incidents │ IAM/UAR (Entra/Google/Okta) │ Internal Audit │
│ Training │ Air-gapped tarball │ AI policy enrichment │
└─────────────────────────────────────────────────────────────────────────┘4. What can run in parallel (the green zones)
4.1 Inside the Platform Floor (W1)
All five streams below kick off on day 1 of W1 with zero dependency on each other:
| Stream | Owner | Deliverable end of W1 |
|---|---|---|
| S1 — Repo + CI + container build | DevOps | main building, image signing, distroless base |
| S2 — BFF skeleton (middleware stack) | Backend eng #1 | Session middleware, CORS, rate limit, request-ID, audit hook (stubs for authz) |
| S3 — Tenancy lib + entity hierarchy | Backend eng #2 | pkg/tenancy + entity CRUD + ancestor-IDs
denormalization |
| S4 — DB/object/email/KeyStore wrapping | Backend eng #3 | Mongo driver, MinIO client, SMTP dispatcher stub, file-backed KeyStore |
| S5 — Seed loader + migration runner | Backend eng #4 | Idempotent, versioned, replayable — can load anything once schemas land |
Join point end of W1: S2 + S3 together = functional BFF that can route by tenant. S4 + S5 together = anything the SME authors can be loaded.
4.2 Auth + AuthZ split (W1–W4)
These two modules look paired but parallelise:
[Auth] Methods Policy SSO OIDC SSO SAML Magic link
(W1-W4) ─────┐ │ │ │ │
└──► IdentityProvider interface ◄──┴──────┴─────┘
│
▼
Session store ──► Step-up ──► Break-glass ──► SCIM ──► Keys
[AuthZ] Resource+Action catalog ──► Role catalog ──► 7-step pipeline
(W1-W3) │ │ │
└─────────────┬───────────┘ │
▼ ▼
pkg/authz library ◄─── SoD matrix ◄── API token evalParallel opportunity: AuthZ finishes by W3 (smaller, purely computational). Auth takes until W4 (external protocols, SCIM, keys). AuthZ lib can ship and be consumed by modules while Auth is still closing.
4.3 Compliance Engine Core (W2–W3, parallel to Auth completion)
As soon as Tenancy + Audit log + Seed loader are up (end of W1), these can start:
| Module | Depends on | Can start |
|---|---|---|
| Atomic Control Library (#3) | Seed loader, tenancy | W2 Mon |
| Framework Scoring (#2) | Control library (can stub), tenancy | W2 Wed |
| Evidence Engine (#4) | Control library, object store, audit log | W2 Fri |
| Risk Register (#5) | Tenancy, audit log, authz lib | W3 Mon |
Key realisation: none of these need Auth to be done. They need tenancy + authz-lib + audit. Auth final sign-off is a W4 security-review event, not a W4 unblock.
4.4 Module Wave (W4–W6) — the big parallel window
Once RBAC middleware is live and compliance engine core is writing evidence, you can run 4 module teams in parallel with almost no coordination between them:
Team A: Vendor (#6) ┐
Team B: Policy (#7) │ All four run in parallel.
Team C: Integrations (#17) │ Cross-module API contracts
Team D: Dashboard (#16) ┘ are frozen by W3 end.
+ Risk polish
+ Action ItemsWhat couples them, and how we decouple:
- Vendor needs Integration "auto-link" → contract freeze W3 Friday; stub on both sides.
- Policy needs Evidence auto-generation → Evidence engine
exposes
emit(control_code, source)by W3. - Dashboard aggregates from every module → every module
publishes a
metrics()endpoint; Dashboard calls late. - Action Items aggregates queues → same pattern as Dashboard.
4.5 Frontend parallelism (W1–W8)
Frontend is not a later phase. It ships alongside backend. Three FE engineers carry:
| FE eng | Owns |
|---|---|
| FE1 | Design system (W1–W2), then Auth screens, Control grid, Compliance pages |
| FE2 | Vendor UX (incl. rich questionnaire builder), Policy rich-text editor (TipTap), diff viewer |
| FE3 | Dashboard, Action Items, Integrations page, Risk heatmap, shared layouts + WCAG |
All three pull from the same design system primitives (W1–W2 platform floor task).
4.6 Extended modules (W9–W12) — everything parallel
By W9 there is no critical path left. Each Extended module is its own connector + UI + seed data + auto-evidence. They fan out freely:
CSPM-AWS ──┐
CSPM-GCP ─┼── 3 teams, near-identical code path, shared connector SDK
CSPM-Azure ┘
SCM-GitHub ─┐
SCM-GitLab ┴── 2 teams, shared SCM SDK
IAM-Entra ──┐
IAM-Google ─┼── 4 teams, shared IdP SDK (reuses Auth's OIDC work)
IAM-Okta ─┤
IAM-OIDC ─┘
Supply Chain ─── 1 team (feeds off SCM connectors + NVD lookup)
VA ─── 1 team (upload + CRUD + linkage)
Incidents ─── 1 team
Training ─── 1 team (public tokenised flow)
Internal Audit─── 1 team
Air-gapped pkg─── DevOps
AI enrichment ─── 1 team (if provider selected)5. What must be sequential (the hard serial points)
These are the non-negotiable ordering constraints. Violating any one of them creates rework.
5.1 The critical path
Entity hierarchy + Tenancy lib
│
▼
AuthZ resource/action/role catalog + 7-step pipeline
│
▼
BFF RBAC middleware (consumes authz lib)
│
▼
Audit log writer (every module writes to it)
│
▼
▶ Every module's write path ◄── unblocked here
│
▼
Evidence auto-generation wiring (needs modules to exist)
│
▼
Dashboard + Action Items (aggregate from modules)
│
▼
Load test (needs real data from all modules)
│
▼
Security review (needs full surface area)
│
▼
Release candidateLength of critical path at theoretical maximum parallelism:
7–8 weeks. At our actual 2-senior team size: ~12 weeks for
v1.0-Core, plus an overlapping W7–W14 Extended phase with contractors —
total programme 12–14 weeks. See RESPONSE.md §6 for the
week-by-week plan against the actual team.
5.2 Serial within Auth
These cannot be flipped:
BootstrapProvider ──► first Org + root Entity + first Admin
│
▼
Domain verification (OOB at bootstrap)
│
▼
Sign-in methods (OIDC/SAML/magic link)
│
▼
Session store ──► Step-up (needs session liveness)
│
▼
SCIM (needs user CRUD + scope eval from AuthZ)
│
▼
Break-glass (needs MFA + alerting + TOTP/WebAuthn)
│
▼
Audit catalog emission (needs all events defined)5.3 Serial within Policy (#7)
Policy record + versioning
│
▼
Rich-text editor (TipTap) + merge fields
│
▼
Version diff (needs two committed versions)
│
▼
Approval workflow (needs versioning + SoD from AuthZ)
│
▼
Acknowledgement campaigns (needs users + published version)
│
▼
Exception/waiver flow (needs published policy to except from)
│
▼
AI enrichment (needs editor + approval workflow; feature-flagged)5.4 Serial within Vendor (#6)
Vendor record + classification (tech/non-tech)
│
▼
Questionnaire template + Excel import
│
▼
External tokenised questionnaire flow (needs template + email + token)
│
▼
Due-diligence doc management + expiry alerts
│
▼
Composite scoring (needs questionnaire responses + doc inventory)
│
▼
Vendor Library adoption (needs record model + scoring)
│
▼
Integration-as-vendor auto-link (needs #17 Integrations model)
│
▼
Reassessment cycles + auto-evidence emission5.5 Hard gates (pass/fail, not timed)
| Gate | When | What must be true | Consequence if missed |
|---|---|---|---|
| G-Foundation | End of W1 | BFF routes a tenant-scoped request with RBAC stub; seed loader works | Entire W2 slips |
| G-AuthZ | End of W3 | 7-step pipeline passes fuzzer; SoD matrix loaded; role catalog loaded | Modules cannot write safely → W4 modules slip |
| G-Auth Security Review | W4 mid-week | Threat model closed; 0 highs outstanding | Can't demo sign-in to client |
| G-Compliance Core | End of W3 | Evidence engine emits auto-evidence for seeded controls | Policy/Vendor auto-evidence untestable |
| G-Integration Contracts | End of W3 | Vendor ↔︎ Integration, Policy ↔︎ Evidence, Dashboard aggregation contracts signed off | W4 teams create incompatible surfaces → rework |
| G-Module Wave Complete | End of W6 | All 4 Core module teams merged to main; E2E smoke green | Can't begin harden wave |
| G-WCAG + Perf | Mid W7 | AA audit findings triaged; P95 budgets met | Can't cut RC |
| G-Security Sign-off | End of W7 | Pen-test remediation complete | Can't ship W8 |
| G-UAT | W8 | Client signs off on Core scope | No GA |
6. Day‑by‑day look at the critical W1
The first week disproportionately sets up whether the programme hits W8 or not. This is what it looks like:
W1 Mon ┌─────────────────────────────────────────────────────┐
│ All 5 platform streams start (§4.1) │
│ Tech Lead + SME begin seed-data schema contract │
│ FE1 begins design system tokens + primitives │
│ Auth eng begins BootstrapProvider interface │
│ AuthZ eng begins resource/action/role catalog │
└─────────────────────────────────────────────────────┘
W1 Wed ┌─────────────────────────────────────────────────────┐
│ Mid-week integration checkpoint (30 min) │
│ BFF skeleton + tenancy lib expose first test route │
│ AuthZ catalog loaded from seed — unit tests green │
│ Seed loader can load a toy framework │
└─────────────────────────────────────────────────────┘
W1 Fri ┌─────────────────────────────────────────────────────┐
│ GATE G-Foundation check: │
│ ☐ Tenant-scoped BFF route live │
│ ☐ AuthZ lib callable (stub role data OK) │
│ ☐ Seed loader + migration runner working │
│ ☐ CI green, images signed, pushed │
│ ☐ Audit log writer functional (append-only proven)│
│ Pass → unlock W2 module skeletons │
│ Fail → W2 recoverable with 2 more days; W3 at risk │
└─────────────────────────────────────────────────────┘7. Concurrency peak
Visually, how many parallel streams are running at each phase:
Pre-W0 │▓▓▓▓▓▓▓▓░░░░░░░░░░░░░│ 8-10 parallel (decisions + design)
W1 │▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░│ 10 parallel (platform floor peak)
W2 │▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░│ 11 parallel (auth/authz + compliance core)
W3 │▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░│ 12 parallel (full foundation + module prep)
W4 │▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░│ 13 parallel (Module Wave starts, Auth finishes)
W5 │▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░│ 13 parallel (Module Wave peak)
W6 │▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░│ 12 parallel (modules merging)
W7 │▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░│ 9 parallel (hardening, fewer new features)
W8 │▓▓▓▓▓▓░░░░░░░░░░░░░░░│ 6 parallel (UAT + final polish)
(Extended)
W9–W12 │▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░│ 12 parallel (Extended fan-out)Note on team-size scaling. The above concurrency map
represents the maximum-parallelism shape of the work — what's
theoretically parallelisable. With a 13-FTE team you could ride
that peak. Our actual team (2 senior engineers for the platform-floor +
Auth + AuthZ + Compliance Core, augmented by 1–2 contractors for
Extended W7–W14) cannot hit those concurrency peaks; instead we accept a
longer calendar (12–14 weeks total instead of 8) so the seniors can
sequence the security-sensitive work properly. See
RESPONSE.md §5 calendar implication and §6 for the actual
delivery plan.
8. What sets us up to fail (patterns to avoid)
- "Let's finish Auth first, then start modules." No — AuthZ lib + Tenancy unblock modules by W3; waiting for Auth's full completion (SCIM, break-glass, keys) costs 2 weeks.
- "Design system later, ship features first." No — inconsistent primitives = WCAG fail in W7 + rework. Build the primitives once in W1.
- "Seed data by engineers." No — SME-led by W0 contract, engineers are the loader, not the author.
- "Security review at the end." No — 2 passes: W4 on Auth/AuthZ, W7 on full surface.
- "Air-gapped is easy, we'll do it at the end." No — clarify by W0 (G-7). If it's a W8 must-have, it steals 1.5 eng-weeks from Module Wave.
- "Agents can own Auth, they're fast." No — per §11 of RESPONSE, crypto/session/tenancy are human-owned, agent-paired.
- "We'll figure out module contracts as we go." No — G-Integration-Contracts gate at end of W3 or teams build incompatible surfaces.
9. Summary table — parallel vs serial by phase
| Phase | Calendar | Parallel streams | Hard serial inside phase | Unblocks next phase |
|---|---|---|---|---|
| Pre-W0 | 2 wks | D1-D10, A1-A7 all parallel | Sign-off ordering only | Kicks off W1 |
| W1 Foundation | 1 wk | 5 platform + 2 auth/authz + 1 FE = 8 streams | None — truly parallel | G-Foundation gate |
| W2-W3 Core | 2 wks | 5-8 streams (authz closes W3, auth continues, compliance engine builds) | Entity → Tenancy → AuthZ → Middleware → Audit | G-AuthZ + G-Compliance-Core + G-Integration-Contracts |
| W4-W6 Modules | 3 wks | 4 module teams × (1 BE + shared FE) + Auth closes W4 + platform polish | Within each module (see §5.3/5.4) | G-Module-Wave-Complete |
| W7-W8 Harden | 2 wks | WCAG + Load + Security + Docs + Ops — all parallel | Fix order: perf → security → UAT | RC1 |
| W9-W12 Extended | 4 wks | 8-10 Extended teams in full fan-out | Almost none | v1.0 full |
10. TL;DR for a stand-up
- Before kickoff: 10 decisions + 7 artefacts, ~2 weeks, done in parallel.
- W1: 8 streams run simultaneously; one hard gate Friday.
- W2-W3: Auth/AuthZ/Tenancy/Compliance engine build out; modules start skeletoning.
- W4-W6: Four module teams in parallel (Vendor, Policy, Integrations+Dashboard, Risk+Action Items).
- W7-W8: Everything hardens in parallel; release candidate.
- Single critical path: Tenancy → AuthZ lib → BFF RBAC middleware → audit log → modules → evidence wiring → load/security → RC. Break any link = slip.
- Do not parallelise: security review against a moving target; rich-text editor work against a not-yet-approved versioning model; any module against a stubbed authz lib.
Done. Documented. Defended.
— Ketan Khairnar