Appendix G - Project Dossier Template

Use the worksheet after memory has had a chance to resist

A dossier is a private source record for one project. It should let you recover the project accurately when an interviewer jumps from architecture to ownership, from a result to its evidence, or from launch to what failed later. It is not a resume bullet expanded into a story, and it is not normally an artifact to send to an interviewer.

Before filling the sections below, collect fragments from memory and from records you are still entitled to consult: design notes, issue history, rollout plans, incident reviews, dashboards, calendars, or feedback. Do not retain or copy employer material you are not permitted to keep. Write sanitized notes in your own words, and mark uncertainty instead of completing it from memory.

Print or duplicate this worksheet for each primary project. Leave space where the evidence is thin. A blank is more useful than a confident invention.

Identification and disclosure boundary

Private project label: _________________________________________________

Approximate timeframe: _________________________________________________

Your role at the time: _________________________________________________

Safe public description: _______________________________________________

Details that must not be disclosed:

• Names: _________________________________________________________________
• Exact figures or commercial terms: ______________________________________
• Architecture, security, or customer details: _____________________________

If removing sensitive material also removes the mechanism that makes the work understandable, choose another project. Sanitization should hide identity, not replace engineering with fog.

Recover the project spine

Write one paragraph before completing the rest of the worksheet. Keep the causal chain intact:

Before: Who experienced what problem, and what evidence described the starting state? Pressure: Which constraint made the existing approach untenable? Change: What did the team change? Contribution: Which part did you own, influence, or implement? Result: What visibly changed, and how do you know? Complication: What failed, remained uncertain, or changed your later practice?

Now underline every jump in that account. Phrases such as “we redesigned the system,” “I led the migration,” and “reliability improved” usually conceal a decision, a boundary, or an unsupported claim. Use the remaining sections to repair those jumps.

Context that makes the choices intelligible

Affected users or operators: ___________________________________________

What they were trying to do: __________________________________________

Starting behavior or baseline: _________________________________________

Consequence of leaving it unchanged: __________________________________

Binding constraints — technical, product, delivery, regulatory, organizational, or operational:

Team and dependency boundaries: ________________________________________

What was genuinely uncertain at the start: _____________________________

Prefer constraints that eliminated plausible choices. “We needed scale” says little; “the migration could not interrupt active reconciliation or lose the audit trail” explains why sequencing and recovery mattered.

Draw the system as behavior

Sketch one consequential path through the system. Show the before-state and after-state only when the difference carries a decision.

trigger
  -> boundary and owner
  -> state change
  -> dependency or handoff
  -> observable outcome

Mark where durable state lived, what could be retried, what had to remain ordered, how failure became visible, and how work was recovered. Add privacy, security, cost, or compliance boundaries when they shaped the design. A list of components is not yet an architecture account.

The path or failure mode most likely to be probed:

Draw the boundary around your contribution

Use exact verbs. “Owned” means you drove a decision or result; “influenced” means your work changed a choice owned elsewhere; “implemented” does not imply that you chose the design.

I owned:

I influenced or reviewed:

I implemented:

Partners or teammates owned:

I depended on or inherited:

A sentence where “we” is more accurate than “I”:

Preserve three decisions as live forks

Complete this block for each consequential technical, product, rollout, staffing, scope, or risk decision. Three well-reconstructed forks are usually more useful than a catalogue of technologies.

Decision one

Question being decided: ________________________________________________

Options that were plausible then: ______________________________________

Evidence available then: ______________________________________________

Binding criterion: _____________________________________________________

Choice and your role in it: ____________________________________________

Cost or failure mode accepted: _________________________________________

What later evidence showed: ____________________________________________

Decision two

Question being decided: ________________________________________________

Options that were plausible then: ______________________________________

Evidence available then: ______________________________________________

Binding criterion: _____________________________________________________

Choice and your role in it: ____________________________________________

Cost or failure mode accepted: _________________________________________

What later evidence showed: ____________________________________________

Decision three

Question being decided: ________________________________________________

Options that were plausible then: ______________________________________

Evidence available then: ______________________________________________

Binding criterion: _____________________________________________________

Choice and your role in it: ____________________________________________

Cost or failure mode accepted: _________________________________________

What later evidence showed: ____________________________________________

Do not judge the alternatives with knowledge gained after the result. A credible rejected option should sound reasonable before the binding constraint defeats it.

Let execution disturb the plan

Record changes of understanding rather than every milestone.

1. First observable step: ______________________________________________
2. What contradicted the plan: __________________________________________
3. Pause, rollback, escalation, or scope change: _________________________
4. What the team changed: ______________________________________________
5. How rollout or adoption continued: ___________________________________
6. What happened after launch: __________________________________________

Include dissent, dependency trouble, manual fallbacks, incidents, support handoff, and later simplification when they changed the work. If you left before learning the eventual outcome, record that boundary.

Keep consequential claims attached to evidence

Repeat this block for each result you expect to mention.

Claim: __________________________________________________________________

Basis — metric, observation, artifact, or report: ________________________

Quality — measured, inferred, estimated, or remembered: _________________

Other plausible causes: __________________________________________________

Disclosure-safe wording: __________________________________________________

Outcomes may include a safer failure mode, reversible rollout, faster diagnosis, clearer ownership, less manual work, or a changed customer result. Use an exact number only when it is accurate, attributable, and safe to share.

Keep the miss and the changed practice

What went wrong or remained imperfect: __________________________________

Which assumption failed: __________________________________________________

What the failure cost: ____________________________________________________

How the team contained or repaired it: ____________________________________

What you would do differently now: ________________________________________

A later behavior another person could observe: ____________________________

“Communicate earlier” is a moral. “Bring the downstream owner into schema review before shadow traffic” is a changed practice.

Close the dossier and retrieve the project

Put the worksheet away before this test. From memory:

1. Explain the project in ninety seconds without hiding the constraint or your contribution boundary.
2. Draw the consequential system path and follow one failure through it.
3. Defend one decision against its strongest alternative using only evidence available at the time.
4. State one result, its source, and what that source cannot prove.
5. Describe the miss and the later change in practice.

Ask a partner to interrupt with “why?”, “who decided?”, “how do you know?”, and “what happened after launch?” Reopen the dossier afterward. Add missing facts, shrink claims that grew while spoken, and remove notes that never helped you reason.

A completed worksheet is not automatically a finished dossier. It is ready when it returns you to the truth of the project quickly, and that truth remains intact when someone else chooses where to probe.

Related links

• The Project Dossier
• Architecture Narrative
• Impact and Evidence
• Failure, Incidents, and Changed Opinions
• Behavioral Question Bank