Appearance
D2.4 · Consolidated list of open decisions and dependencies
| Work stream | WS 2 — Target State Architecture |
| SOW source | Schedule "A", WS 2 deliverables, third bullet |
| Status | 🟡 In progress |
| Indicative window | Weeks 2–4, closed at WS 2 close |
What the SOW asks for
Consolidated list of open decisions and dependencies
Supported by §3 item 3 and WS 2 activity 4: "identify architectural decisions, trade offs, dependencies, constraints and areas requiring further client decision or validation."
The live artifact
This deliverable is not written at the end — it is docs/decisions/open-questions.md, maintained continuously from WS 1 onward and submitted as it stands at WS 2 close.
An item leaves the list in exactly one of two ways: it becomes an ADR in the decision log, or it is explicitly closed with a note recording how. It is never quietly dropped.
What it contains
Per item: the question or dependency, the domain it belongs to, the owner who must answer it, the date it is needed by, and its status. Items that need explanation carry a note beneath the table rather than being compressed into a cell.
Why this deliverable is the honest one
The SOW asks us to identify "areas requiring further client decision or validation" — to surface them, not to resolve them unilaterally. This is the deliverable where a plausible guess is worse than an admission.
It also sits on top of a live disagreement. The segment assessment closes with 29 questions for the solution architecture team; the readiness review closes with seven more. Those are the client's own open items, not ours. Where they overlap with the target state we are documenting, this register should carry them — attributed to their source — rather than pretend they were discovered here.
Some of them are genuinely ours to answer, and the register should say so. "Where does the authorization decision live once display is aggregated?" is an architectural question, and answering it is what WS 2 is for. "Where is the Privacy Office coverage letter?" is not.
Categories
| Category | Meaning | Resolution path |
|---|---|---|
| Architectural decision | A choice with a trade-off that we can make | ADR in the decision log |
| Client decision | A choice only Manulife can make | Named owner and needed-by date |
| Validation | Something we believe but have not confirmed | Confirmation from a named source |
| Dependency | Something outside the architecture that gates it | Owner, and the roadmap item it blocks |
| Constraint | A fact the architecture must accommodate | Documented in docs/architecture/; not resolvable |
The categories matter because they route differently. Mixing a decision we should be making into a list of things we are waiting on the client for is how an engagement stalls politely.
Where the content is being assembled
- The register itself: open-questions.md
- Resolved items: Decision log
- Source-attributed questions: per-artifact pages under Client resources, each of which ends with the questions that source raised
Acceptance
Written acceptance from Manulife's project manager per SOW §5. Carried forward into WS 3, where dependencies become roadmap inputs — a dependency that gates a target state capability is the same dependency that gates the roadmap item delivering it.