Skip to content

An Alembic resource · Version 1.1

A software pilot scorecard that keeps the evidence

Compare a tool with your current method using agreed requirements, representative cases, correction effort and a reviewable decision record.

Decide what would change your mind

A useful software pilot starts with the task and an independently checked expected result. Record what the current method does, give the candidate a fair setup, and retain the first attempt as well as any retest.

Use these finding labels instead of a weighted total:

Finding Meaning
Met The observed case satisfies the requirement you agreed beforehand.
Not met The result falls short; retain what happened and why it matters.
Not assessed You do not yet have evidence for this requirement.

A failed access check cannot be cancelled out by a pleasant interface. Nor does an untested requirement count as a pass.

Include an ordinary case and relevant awkward cases: missing information, a duplicate, a correction or an interrupted handoff. Choose cases from your work and record their limits. Record why those cases are relevant; a small sample cannot settle every possible use.

The full scorecard includes a pilot agreement, a case log, a fictional example where the team postpones rollout, and a final decision record. It shows how to record unresolved checks without counting them as passes.

Start with the blank pilot case log or inspect the fictional example CSV. Both CSVs are editable tables without formulas or automatic ratings. The full guide includes the tables and decision instructions in one document.