Skip to main content
Adobe Commerce Expertise Atlas

Manual evidence tool

Case-to-Workstream Evidence Checklist

Check one public Adobe Commerce case against one buyer brief. Keep the useful match, show the gaps, and move named-team questions into the proposal.

By Nina Kavulia, Principal Analyst Published by B2B TechSelect Last updated

Case record / 01

Identify the case before using it as proof

Print one copy per case. Copy only what the public source states. If a field is missing, write “not established” instead of filling the gap from memory.

  • Named customer: _________________________________________________
  • Provider: ________________________________________________________
  • Public case URL: _________________________________________________
  • Page title: ______________________________________________________
  • Checked date: ____________________________________________________
  • Reviewer: ________________________________________________________
  • Exact platform wording: __________________________________________

Route match / 02

Test the shape of the work first

A famous customer or a large outcome does not make a case relevant. Compare the route that produced the work.

Buyer brief compared with the public case
Route fieldBuyer briefPublic caseStrong, partial, no, or unclearSource passage or note
Business workflow________________________________________________
Adobe Commerce estate________________________________________________
Connected systems________________________________________________
Data direction and timing________________________________________________
Storefront or experience________________________________________________
Markets and operating context________________________________________________
Delivery stage________________________________________________
Starting risk or constraint________________________________________________

Workstream match / 03

Tie every claimed match to a visible passage

Use the expert role map to define your required work first. A checked workstream means the source supports a narrow statement, not that it proves the whole team.

Workstream evidence map
WorkstreamRequired in brief?What the case statesExact source locationEvidence boundary
Business workflow and analysis________________________________________________
Architecture and platform decisions________________________________________________
Commerce backend or B2B behavior________________________________________________
Storefront, accessibility, or performance________________________________________________
Integration and data________________________________________________
Quality and release________________________________________________
Security or privacy________________________________________________
Delivery, operations, or continuity________________________________________________

Evidence class / 04

Label what kind of proof you have

Use one of the LATTICE-11 evidence classes for each material statement.

Named project record

A provider-published case names the customer and route context. Its outcomes remain provider-reported and project-specific.

Official organization record

An official page supports only the company capability or status shown on that page.

Dated market signal

A time-stamped third-party observation supports only the visible signal recorded on the checked date.

Named-team evidence required

The proposal must establish people, allocation, availability, ownership, working interfaces, and terms.

Not established in public sources

The reviewed source does not establish the point. That does not prove the capability is absent.

Narrow the sentence

If a source supports only part of a statement, keep the supported part and mark the rest for verification.

Outcome check / 05

Keep every result attached to its case

Do not turn a provider-reported case result into a forecast or contract target. Record the missing context as carefully as the visible number.

Outcome evidence record
Exact outcome statementBaselinePeriod and populationMeasurement ownerAttribution and limits
____________________________________________________________
____________________________________________________________
____________________________________________________________

Use wording such as “the provider reports” when the case source supplies the result. If the source does not show the baseline, period, population, exclusions, or measurement owner, write that those details are not established.

Proof boundary / 06

Separate case proof from proposal proof

A company case and a current proposed team answer different questions.

What the public case can and cannot establish
QuestionPublic case may supportStill verify in proposal or contract
Was this route delivered?The named workflow, system, stage, or risk stated in the caseWhether the current brief is similar enough
Who did the work?Only people or roles explicitly named in the sourceProposed names, role ownership, allocation, and references
Are credentials current?Only exact credentials and dates shown in an official recordHolder, title, level, active status, and assignment
Can the team start?Nothing unless the source states a relevant dated commitmentAvailability, start date, location, overlap, and substitution
Will the same result occur?A project-specific, attributed historical resultBaseline, target, method, dependencies, acceptance, and remedies
Are controls suitable?Only controls explicitly described for the caseRepositories, access, QA, releases, incidents, security, and exit

Final check / 07

Complete all twelve checks

  1. Record the named customer and public source URL.
  2. Confirm that the source explicitly identifies Adobe Commerce where the brief requires it.
  3. Compare the named business workflow with the buyer workflow.
  4. Compare connected systems and data paths.
  5. Compare the delivery stage and starting condition.
  6. Map each supported workstream to an exact source passage.
  7. Record missing or unclear workstreams as not established.
  8. Copy each outcome carefully and keep its provider attribution.
  9. Check baseline, period, population, exclusions, and measurement owner.
  10. Do not treat a company case as proof of the proposed people.
  11. Write the case-fit boundary and unresolved proposal checks.
  12. Record reviewer, checked date, decision, and next action.

Decision record / 08

Write a bounded conclusion

  • Route fit: strong / partial / no match / unclear
  • Best-supported sentence: _________________________________________
  • Important limitation: _____________________________________________
  • Named-team evidence required: ____________________________________
  • Keep on shortlist? yes / no / hold for more evidence
  • Next action and owner: ____________________________________________

A strong case match is still a reason to ask better proposal questions, not proof of a future outcome. Transfer the unresolved fields to the expert-team SOW worksheet.

Method reference: LATTICE-11 Expert Team Fit Method. Last updated .