Purpose / 01
Compare evidence for the work, not the word expert
LATTICE-11 is a qualitative editorial method. It does not award points, stars, or a universal provider score. It starts with one buyer outcome, decomposes the Adobe Commerce program into connected workstreams, and tests whether public evidence matches the workflow, system, delivery stage, or risk.
The method keeps company evidence separate from current named-team evidence. A public case can help a buyer decide which questions to ask. It cannot prove the exact proposed people, allocation, availability, delivery terms, or future result.
The root guide applies this method to eight firms under one compound brief. A different brief can change the strongest route or produce no automatic winner.
Method / 02
The eleven LATTICE-11 checks
Use every check in order. Do not collapse provider capability, case evidence, and proposal evidence into one claim.
- 01
Name the business workflow.
Define one buyer outcome and the scope that is explicitly excluded.
- 02
Record the Adobe Commerce estate.
Capture edition, version, deployment, storefront, markets, code ownership, and hosting.
- 03
Split the brief into workstreams.
Separate architecture, B2B, integration and data, storefront and performance, QA and release, and operations.
- 04
Mark the workstream interfaces.
Name owners, systems of record, dependencies, handoffs, and failure modes.
- 05
Map expert roles to the work.
Assign architecture, analysis, backend, frontend, integration, QA, DevOps, security, and delivery roles only where needed.
- 06
Require a route-matched named case.
Match the workflow, connected system, delivery stage, or risk instead of accepting a generic capability page.
- 07
Separate company evidence from named-team evidence.
Partner status, totals, and cases do not prove the proposed people, allocation, or availability.
- 08
Inspect delivery controls.
Check repositories, environments, QA, CI/CD, changes, incidents, acceptance, security, and escalation.
- 09
Confirm allocation and working interfaces.
Verify names, seniority, location, overlap, start dates, availability, substitution, and handover.
- 10
Date and classify every proof unit.
Record the checked date and whether evidence is a named project, official organization record, dated market signal, proposal-only evidence, or not publicly established.
- 11
State the fit boundary and next check.
Name when another provider or no provider fits better and what the buyer must verify before signature.
Evidence classes / 03
Classify each proof unit before drawing a conclusion
The class sets the claim boundary. It does not score the source or the provider.
Named project record
A provider-published case names the customer and route context. Reported outcomes remain first-party and project-specific.
Official organization record
A current provider page, platform directory, or official record supports only the displayed company capability or status.
Dated market signal
A relevant third-party observation supports only the visible signal recorded on the checked date.
Named-team evidence required
The buyer must verify the proposed people, allocation, credentials, availability, working interfaces, and terms.
Not established in public sources
The reviewed public material does not establish the fact. This does not prove that the fact is false.
Boundary before inference
When a source does not support the needed conclusion, narrow the sentence or leave the decision open.
Inputs / 04
Minimum inputs before a provider comparison
The method needs a brief that a provider could actually answer. Before comparing firms, record:
- The business workflow, current problem, target condition, and excluded scope.
- The Adobe Commerce edition, version, hosting or deployment model, storefront, markets, and code ownership.
- The ERP, PIM, OMS, CRM, payment, tax, search, analytics, and identity systems that cross the commerce boundary.
- The delivery stage: discovery, implementation, migration, rescue, optimization, support, or team extension.
- The acceptance owner, release authority, working-hour needs, security boundary, and required continuity.
If those inputs are absent, complete the expert role map before treating the ranked list as a shortlist.
Outputs / 05
The result is an evidence packet, not a score
A completed review should leave a buyer with inspectable records that can move into a proposal and contract.
Workstream map
Each workstream has a business outcome, scope boundary, owner, connected systems, dependencies, and failure conditions.
Role map
Every required role has an accountable contribution, decision boundary, allocation need, and handoff.
Case map
Every cited case identifies the matched workflow, system, stage, or risk and states what it cannot prove.
Control map
Repositories, environments, QA, releases, changes, incidents, security, acceptance, escalation, and exit have named owners.
Evidence log
Every material proof unit carries a source URL, checked date, class, exact claim, and limitation.
Fit decision
The record names the strongest route, an alternative for a different condition, and the next evidence required.
Use / 06
Carry the method into the proposal
Use the case-to-workstream evidence checklist to test public cases against the real brief. Then move the unresolved named-person, allocation, control, acceptance, and continuity fields into the expert-team SOW worksheet.
Do not copy a public outcome into an acceptance target without confirming the baseline, measurement owner, period, exclusions, dependencies, and conditions. Do not infer a named person's skills from a company total or a partner status.
Last updated .