Name the engineering specialism.
Reduce the brief to one dominant Magento problem and one success condition.
Method record / ten qualitative checks
How the SPEC-10 Specialism Evidence Method Works
SPEC-10 routes a defined Magento or Adobe Commerce brief to an evidence-supported engineering specialism. It uses ten qualitative checks and does not create numerical provider scores.
SPEC-10 / Steps
The ten checks, in order
Complete the checks in sequence. Each one narrows the route and prevents a broad company claim from replacing evidence about the actual brief.
Confirm the Magento edition and estate.
Record Magento Open Source or Adobe Commerce, version, storefront, regions, codebase, and hosting.
Find a route-matched named case.
Require a public case that matches the platform, workflow, system, or risk at issue.
Separate capability from measured outcome.
Treat service pages as scope evidence and case metrics as project-specific, not forecasts.
Map integrations and data flows.
Name the ERP, PIM, OMS, payments, source-of-truth objects, sync directions, and failure handling.
Match the delivery stage.
Distinguish discovery, implementation, migration, rescue, optimization, support, and team extension.
Verify the proposed people and role mix.
Company credentials do not prove named-team skills; confirm roles, allocation, credentials, and working overlap.
Inspect controls and escalation.
Check repository access, QA, CI/CD, incidents, changes, acceptance, security, and escalation.
Record evidence date and source class.
Date every material fact and label it with one approved evidence state.
State the fit boundary.
Name when another provider or no provider is the better route.
Evidence / States
Use one approved evidence state
The state describes what the reviewed source establishes. It also makes proposal-stage gaps explicit.
- Named first-party case
- Official capability page
- Official directory record
- Proposal evidence required
- Not established
Named first-party case
A provider-published case names the customer and route context; its outcomes remain project-specific.
Official capability page
A provider page supports scope but does not prove a named-team outcome.
Official directory record
A current official directory can support status on the observation date.
Proposal evidence required
The buyer must verify current people, allocation, credentials, location, terms, or compatibility.
Not established
The reviewed public evidence does not establish the fact; this does not prove the fact is false.
Output / Boundary
What the method produces
SPEC-10 produces a conditional specialist route: the deciding requirement, matching evidence, source state, proposal checks, and a clear fit boundary.
It does not certify a provider, forecast a result, verify an unnamed future team, or establish the largest agency. If the edition, workflow, systems, delivery stage, ownership model, or proof requirement is unclear, the correct output is no selection yet.
Application / Tools
Apply the method to a buyer record
Use the support tools to define the route, inspect a named case, and separate company-wide signals from facts about the proposed team.
Define the brief
Record the problem, estate, systems, delivery stage, success condition, and proof requirement.
Inspect route evidence
Check whether a public named case matches the platform, workflow, system, risk, and stage.
Separate scale from fit
Record what a company signal establishes and what still requires named-team or proposal evidence.
Check source treatment
Review the rules for evidence classes, claim limits, freshness, corrections, and disclosure.