Decision log

Every decision this engagement makes, one file each, with the alternatives that lost and why.

The SOW makes "key architectural decisions and rationale" and a "consolidated list of open decisions and dependencies" explicit deliverables (D2.1, D2.4), so this directory is a deliverable rather than a set of notes.

The log

ADR	Decision	Kind	Status
0001	Archify with typed JSON IR for diagrams	Engagement tooling	Accepted
0002	Curated version snapshots over git-derived history	Engagement tooling	Accepted
0003	VitePress as the docs shell around the diagram pipeline	Engagement tooling	Accepted
0004	A client-side password gate, and why it is not access control	Engagement tooling	Accepted

Open items that are not yet decisions live in open questions.

Two kinds of decision

The log holds both, and the distinction matters to the reader:

Engagement tooling — how we work and how the deliverables get made. ADRs 0001–0004 are all of this kind. Real decisions with real trade-offs, but internal: Manulife inherits their consequences only if this repository is part of the handoff.

Target state architecture — decisions about the Unified Portal itself. None recorded yet; they arrive with WS 2. These are the ones the SOW means, the ones that go in front of an executive audience, and the ones where recording the rejected alternative is not optional. The candidate list is in the WS 2 task notes.

Both stay in one numbered sequence. Splitting them into two directories would mean deciding which bucket each new decision belongs in before writing it, which is exactly the kind of question that stops people writing things down.

Conventions

• Filename NNNN-kebab-case-title.md, numbered sequentially, never renumbered.
• Copy 0000-template.md to start.
• Status is one of Proposed, Accepted, Superseded by NNNN, or Rejected. A decision is never deleted — supersede it, so the reasoning trail survives.
• Record what was rejected, and why. On this engagement the trade-off is the deliverable. A decision without its alternatives cannot be defended in an executive readout, and the client's own architecture function has already demonstrated the standard of scrutiny to expect — see the segment assessment.
• Mark decisions needing client validation. The SOW calls out "areas requiring further client decision or validation" as something we surface, not resolve unilaterally. A decision we have taken provisionally, pending confirmation, should say so in its status line rather than read as settled.
• One decision per file. If it needs "and also", it is two ADRs.

Relationship to the client's own decision records

Manulife's material contains decisions recorded in other places and other formats — the two Key Design Decisions in the GARB ADS, both marked pending LARB approval while build proceeds, and an ADR-001 for Redis geo-replication referenced in the readiness review.

We do not restate those here. Where a target state decision of ours depends on one of theirs, the ADR cites it and records what happens if it lands differently. Their decisions are inputs and constraints; this log holds ours.