Delivery Team Schematic

BA drafts the requirement first — this isn't a paired loop by default. Whether UX gets involved is a real decision, not automatic: no screen or journey impact → straight to the Architect. Contained UX impact → BA hands to UX, UX hands it back, BA finalizes. Genuinely complex or ambiguous → BA, UX and the Architect work it as a trio. All three routes land on the same place: a finalized requirement, ready for approval.

Not called "Solution Architect" here on purpose — this is whichever architect the change actually needs, solution-level, technical-level, or both. Same mechanism as always: this isn't a pause, it's a state transition. Approve flips the field to approved, reject flips it to rejected; a Hook watches for either and fires the matching next step, even days later with nobody watching.

The Architect designs; then QA, Risk and Data all fire at once off that one design — not staged one after another. QA's check is concrete: it reads the design against use-cases/ and test-scenarios/, the actual existing scope, not an abstract regression pass.

Runs alongside Zone C, independent of it. Only when the Architect's design touches a shared standard — design-system/ or data-model/, not just this capability's own files — a folder-watching Hook fires an isolated Retrofit Scan, which finds every artifact still referencing the old standard and writes a backlog that surfaces at Zone E alongside everything else.

Not straight to BA, not straight to the PO. Every QA or Risk finding lands with the Architect first. If it's resolvable with a different implementation approach — the requirement itself doesn't change — the Architect just decides and redesigns; QA, Risk and Data re-check the revision back in Zone C, no one else involved. Only if the fix actually changes what was asked for does it go further: back to BA to revise the requirement, then back through Zone B for PO re-approval.

Whatever survives Zone D — a clean pass, a resolved-in-Zone-C revision, or a genuine requirement change — lands here. If you're watching, you just see it; if you've stepped away, PushNotification is what pulls you back for a decision worth interrupting you for. Every decision writes to decisions/, append-only. Baseline resets and Memory updates are separate, deliberate, ongoing — never triggered automatically by any of the above.

Every skill file has exactly one owner, and this is also where the "what happens to my team" question resolves: the person who used to do this work full-time now owns the skill that represents it — reviewing its output, rewriting it when it's wrong. Edit rights stay with the owner; suggestion rights are open to any role. Same pattern for all six skills, shown here for one.

Every write from any zone above passes through these gates before anything fires — schema, duplication, and runaway-loop checks, in that order. This is what makes it safe to let Hooks act on real artifacts unattended: nothing here is a live pause, each is a deterministic check on the write itself.