# Portfolio Patterns

Use these patterns to choose the right portfolio move before writing.

## Portfolio As Proof System

A portfolio should prove judgment, contribution, and decision quality. It is not a gallery of attractive artifacts. Each case should answer:

- What problem or decision context existed?
- What did the candidate actually do?
- What artifact, method, or decision shows the work?
- What changed, was learned, or became possible?
- What should not be claimed yet?

## Reader Speeds

Design for three reader speeds:

- 10-second scan: title, role, case thesis, recognizable proof.
- 2-5 minute review: problem, contribution, artifacts, outcome, fit.
- Deep interview review: decisions, tradeoffs, constraints, evidence, reflections.

If the case only works at one speed, revise the hierarchy.

## Case Thesis Pattern

Use this as the first stabilizing sentence:

```text
This case shows [capability] by tracing how I used [method/artifact] to address [problem] and influence [decision/outcome].
```

If any slot is unsupported, mark it:

```text
This case shows [capability] by tracing how I used [method/artifact] to address [problem] and influence [MISSING INFO: decision or outcome].
```

## Evidence To Case Flow

```text
Raw facts -> Evidence check -> Case thesis -> Artifact captions -> Case narrative -> Audit -> Share-ready version
```

Do not skip the evidence check. Strong writing cannot rescue unsupported claims.

## Case Card Before Case Study

When project facts are messy, create a one-page case card first. A case card should stabilize:

- reader hypothesis
- problem
- role
- methods
- artifacts
- decision influenced
- outcome or learning
- confidentiality
- missing proof

Only expand into a full case study after the case card has enough support.

## Artifact Caption As Proof

Captions are not labels. A useful caption explains:

```text
[Artifact] + [what it shows] + [why it mattered] + [decision it influenced]
```

If the decision is unknown, say so rather than guessing.

## Interview Continuity

A case study should prepare the user to answer:

- What exactly was your role?
- What did you decide or influence?
- What evidence supports the outcome?
- What would you do differently now?
- What cannot be shared publicly?

## Public Website Caution

Do not turn case-study work into website planning unless the user explicitly asks. The default deliverable is a case, card, caption set, deck outline, or leave-behind.

When the user explicitly asks for contractor or service-business proof, start
with buyer risk and service fit before visual polish:

```text
buyer problem -> service offer -> case proof -> artifact -> decision influenced -> next action
```
