Distinguish a technical case study from a product outcome claim

A technical case study can explain how a system works without claiming a measured customer result. Keep those evidence requirements separate when writing a portfolio page. A repository can document an encoder fallback, but it cannot by itself establish how much time a customer saved.

Attach claims to evidence

Use a small evidence ledger before drafting. These entries are illustrative classifications rather than a product evaluation.

claims = [
    {"claim": "A software fallback path is documented", "evidence": "README"},
    {"claim": "A fixture export succeeded", "evidence": "test_run"},
    {"claim": "Customers exported faster", "evidence": None},
]
unsupported = [row["claim"] for row in claims if row["evidence"] is None]
assert unsupported == ["Customers exported faster"]

The test-run entry would require an actual saved run before publication. A label in a ledger does not create that evidence. For measured outcomes, keep the denominator, comparison period and method with the result so that another reader can assess what changed.

Implementation documentation and actual test observations support different claims; the evidence check controls case-study wording.

Read the optional workflow carefully

ShortForge's README describes a local desktop video workflow and an optional OpenRouter AI layer. Its current portfolio description explains that enabling external AI sends selected inputs to a provider. A blanket statement that every operation stays on the computer would conceal that optional network boundary.

The README also describes safeStorage use in the main process. Electron's documentation gives that mechanism a platform-specific protection scope. Writing "encrypted at rest" should not expand into a promise that no other software can obtain the value while the user is logged in. Keep the claim at the level the documentation and any actual tests support.

Say what was exercised

An architecture review can explain intended data flow. A local fixture can show one observed result under declared versions. A deployed workflow test can establish behavior at a particular time. Customer outcomes require a different source, such as an agreed measurement with real usage data and appropriate permission to report it.

This case-study reading used the public documentation and portfolio description; it did not authenticate into ShortForge or measure customer exports. That boundary lets the explanation stay useful without inventing performance, revenue or audience reach.

References: ShortForge README, project overview and Electron safeStorage.