Starting condition
Name the business context, systems, owners, volume, delay, error, or manual work before implementation.
EVIDENCE TEMPLATE · NOT A CLIENT CASE STUDY
Document implementation proof without inventing the outcome.
This is the structure Hyperlane Labs uses to turn completed, approved project evidence into a future case study. It is not a claim that a client achieved these results.
Scope and boundary
List what Hyperlane changed, what remained outside scope, and which third-party systems or dependencies were involved.
Acceptance evidence
Record representative tasks, exception cases, recovery checks, dates, and the person who accepted the result.
Verified outcome
Report only a measured result with its method and period, or a clearly labeled qualitative outcome approved by the client.
Limitations
State what the implementation does not establish and which results should not be generalized to another business.
Publication approval
Obtain permission for the business name, quotation, screenshots, metrics, and any identifying implementation details.
PUBLICATION RULE
Specific, attributable, and honest.
- Do not infer a percentage improvement from an anecdote.
- Do not identify a client without permission.
- Do not present a demo, proposal, or internal test as deployed customer work.
- Keep the measurement method and relevant limitation beside the result.
START A CONVERSATION
Have an implementation ready to document?
Bring the baseline, acceptance evidence, result, limitations, and client approval so the story can be published accurately.