Implementation proof pipeline

Use this pattern when an implementation plan must show both delivery and verification, especially when dates are sparse or clustered.

One job

Answer three questions in five seconds:

1. What exists?
2. What has been proved?
3. What must happen next?

When a Gantt chart is the wrong shape

A Gantt chart needs meaningful start dates, end dates, and durations. Do not invent them. When most entries share one date, or several are undated, use a proof pipeline instead.

The pipeline follows the real sequence of work. Each milestone carries:

• a phase or gate;
• a short outcome;
• one status;
• the latest known date;
• evidence, or the exact proof still missing.

Status law

Keep construction and verification separate.

Never label configured work as complete. In eRegistrations, green means database evidence was read, not merely that a component or BOT was built.

Composition

Use three levels of detail:

1. Executive summary: one sentence plus a small integrated status strip.
2. Proof pipeline: ordered milestones with state, date, and inline evidence.
3. Next sequence: two or three dependency lanes that turn the remaining work into an executable order.

Filters may reduce noise, but the default view shows the whole path. Evidence opens inline, never in a modal. Desktop uses a horizontal rail when the sequence fits; mobile preserves the same DOM order in a vertical rail.

Data integrity

• Do not add avatars unless the source records accountable people.
• Do not show percentages when the denominator is ambiguous.
• Treat repeated subchecks inside one phase as subchecks, not new phases.
• Name every blocker. Avoid a generic "blocked" state with no dependency.
• Link every evidence claim to the report, run, row, or survey that proves it.

Proof chronology

Do not compress away the audit trail. For each proven phase, preserve the exact time, the test result, and the concrete output when the source records them. Repeated checks inside one phase stay together, but their separate times remain visible.

Evidence can age while the implementation continues. Give historical reports an explicit cutoff, point current blockers to the freshest source, and never let an older "not proven" section override a later verified run.

Keep these states distinct:

• repaired configuration;
• configuration validated;
• publish confirmed;
• end-to-end run confirmed.

A later state may depend on all earlier states. Never infer one from another.

Document chain

Make the implementation plan the canonical status home. Supporting documents should form one explicit path:

Execution board → visual evidence → detailed test report → build log or preparation evidence

Every supporting document links back to the execution board. The board links each phase directly to the evidence that supports it. A separate full-screen board may remain available, but it is a view of the canonical board, not a competing status source.

References

The pattern combines three established project-management ideas:

• Linear: milestone progress contextualized on a timeline.
• Asana: portfolio-level status and progress overview.
• Jira: explicit dependencies, bottlenecks, and release gates.

The visual world follows the eR service family: warm beige paper, near-white surfaces, dark ink, and colour reserved for state.

Separate runner, browser, workflow and database outcomes

Do not collapse a test run into one pass or fail label. Record each observable layer separately:

• Browser passed: the scripted checks completed in the interface.
• Runner stopped: the automation stopped on an assertion or timeout. This is not automatically a service failure.
• Submitted or pending: the application entered the workflow.
• Workflow desk result: the named processing desk completed, failed or is waiting. A later unrelated desk failure does not erase an earlier successful desk result.
• Database readback: the expected rows were read from the authoritative databases.

A phase is proven only at the layer its acceptance criterion requires. A 60 / 60 browser result can prove the form path while the database phase remains blue and awaiting readback.

For dense horizontal boards, put phase numbers on the timeline nodes above the cards. Keep card headers for the owner and current state so the execution content remains visually dominant.

Align timeline cards by information band

Repeated execution cards must scan horizontally, not read as separate documents. Give every card the same fixed bands:

1. owner;
2. short title;
3. state and date;
4. one aligned disclosure for narrative and evidence.

Make the phase number on the timeline node larger than the card title. Keep the title quiet and short. Put explanatory paragraphs and proof links inside the disclosure so collapsed cards remain equal in height and every state sits on the same horizontal line.

Inside each disclosure, explain the phase with three stable bullets: Purpose, Done, and Next. Put the phase title first in the card and reduce the owner to a small, labelled icon in the top corner. Every state needs a time: show the event time when known, a status-check time for waiting work, or say explicitly that the time was not recorded. Do not put a person's name in the status label. Describe the concrete human action under Done.

Keep operational card typography quiet: medium-weight titles, regular timestamps, restrained status labels, and a short disclosure label. Colour should carry state before heavy type does. On this execution board, phase numbers and timeline nodes use the original left-side anchor so the eye enters each card from the same edge as its title.