A score you cannot inspect is itself an ungoverned ranking layer.

The premise

Most governance layers are stochastic. That is the bug.

Agentic commerce channels rank and re-rank your products through two opaque layers you cannot audit. The one lever you hold is input quality. Teams reach for a model to assess it — and in doing so make the governance layer itself non-reproducible.

The component you build in this workshop takes the opposite position. No model calls exist in the scoring path. A score must be reproducible bit-for-bit from SKU data plus rubric version. An LLM may consume readiness records; it may never produce them.

That single constraint is what makes everything downstream possible: evidence you can cite, a rubric you can version, a refusal you can defend, and an audit trail that means something six months later when someone asks why a SKU shipped.

What you build

Four tools, four resources, one gate

You implement the MCP surface end to end — not a toy version. Resources are read-only and ungated. Tools carry consequence tiers, and the tier decides whether a human has to sign.

The tier assignment follows one rule, and you will spend a session arguing about it: anything that reads or computes is automatable; anything that publishes into a system whose behaviour you cannot audit is not.

The rubric is itself exposed as a resource, at catalog-readiness://rubric. That is deliberate, and it is the thesis of the whole workshop in one design decision.

Curriculum

Six units across two days

Every unit ends with working code and a decision you had to defend. You bring a catalog export; you work on yours, not on a fixture.

The teaching case

How a compliance defect scored 85.7 and passed

A food SKU was missing its allergen disclosure. It scored 85.7 and landed in AGENT_READY.

Nothing malfunctioned. The rubric worked exactly as specified — the SKU was strong on attribute completeness, clean on structured data, well photographed. A weighted average did what a weighted average does: it absorbed one failing dimension into five passing ones and returned a number above the threshold.

The fix is architectural, not numerical. Raising the threshold would not have caught it; a different weighting would only have moved the failure. What catches it is a hard rule at the staging boundary that rejects the SKU outright, sitting outside the scoring path entirely, where no average can reach it.

// Gate invariant — enforced at stage, not scored
if (isDisclosureRequired(sku.category) && !hasDisclosureEntry(sku)) {
  return reject("POLICY_FAIL", {
    rule:      "hardRules.compelledDisclosure",
    rationale: "Compelled disclosure absent. Not a scored deduction."
  });
}

You will spend a full unit on the general form of this problem: identifying which of your own rules are being quietly averaged away right now, and moving them out of the score and into the gate. Most teams find at least one.

Format

Small cohorts, your catalog, working code

• Two days. Six units, each ending in something that runs.
• Small cohort. Capped deliberately — this is a workshop, and a workshop that cannot see everyone's screen is a lecture.
• Your data. Bring a catalog export. You build against it, and you leave knowing your own readiness position.
• Remote or on-site. Remote runs as two consecutive days. On-site available for teams; travel quoted separately.
• You keep everything. The component, the rubric file, the fixture harness, the audit scaffolding. No runtime dependency on us.

Cohorts are scheduled as demand forms rather than against a fixed calendar, so the group is always the right size and always roughly the right level. Register your interest and you will be told the next date before it is public, with a place held while you decide.

Register

Take a place in the next cohort

Tell us what you are building against. Cohorts form around the problems in the room, so the detail here changes what gets taught.

Questions

Before you ask