The Shelf / The KYC Compliance Audit canon v3.3.2 · gate PASS

Worked Example: the KYC Compliance Audit (the JTBD door, regulated-domain flavor)

Deliverable of: the module package, artifact 5. Built against: canon v3.3.2 (2026-08-29). Source: the first live teach (a founder-to-lead 1:1, 2026-08-26), lightly formalized; roles generic. What it adds to the example set: the JTBD door with NO pain behind it (nothing is broken), a regulated domain where part of the ontology is IMPORTED from an external document (the construction-grounds law in miniature), and enforcement as a release gate.

The door

No pain. Nothing has failed. The compliance lead's job to be done: "I want to know that the app in production conforms to my compliance manual." Named hirer: the compliance lead. Cadence: every release. Decision changed: whether the release ships. Failure cost: regulatory exposure discovered by the regulator instead of the audit.

Ontologize (only as far as the job demands — the depth rule)

The job's own words expose the missing nouns. "The app": WHICH app? So —

  • Table of apps, each reified with an ID (APP-1, APP-2 ... one per market entity), because "the app out there" is not a citable noun until each instance carries identity, and releases are per-app.
  • Table of compliance manuals, versioned (group-level and per-app), IMPORTED: the manual already exists as an external document; the ontology prunes it into citable, versioned units rather than inventing anything (settled + externalized = import ground).
  • Table of audits: one row per audit run — app ID + build number, manual version, run timestamp, verdict (pass/fail).
  • Table of audit findings: severity (high/medium/low), description, status; child of an audit row.

Nothing else. No risk taxonomy, no control library, no GRC suite: the job demands conformance-per-release, and the depth rule stops the ontology there.

Processize

One SOP on the release clock: before any app release ships, run the audit — this build against the current manual version — and record the verdict. One enforcement rule, Gate mode: a failing audit blocks the release until findings are resolved or accepted by the named owner. The gate is what makes the structure real: without it, the audit is a report; with it, the audit is part of the write path to production.

Log

"Audit run 26 Aug, 21:00: APP-2 build 123 against manual v5 — verdict FAIL, findings F-1 (high), F-2 (low); release blocked, returned to product." One line, fully citable, answerable years later — the row a regulator, a board, or an acquirer's diligence actually asks for.

The loops

Fast loop: the gate fires per release; exceptions (failing audits) reach the compliance lead loudly; passing audits make no noise. Slow loop: a manual revision mints a new manual version; the next audit runs against it — the ontology absorbs regulatory change as a versioned row, never a rewrite. Findings that recur across audits are information about the product process, not the audit: route them to Garden.

Why this example earns its slot

The lifting pair teaches the layers; the marathon teaches the loops; the campaign register teaches politics. This one teaches the JTBD door proper (proactive, pain-free, and still fully bounded), identity doing regulatory work (an unversioned manual or an ID-less app makes the audit's claim unverifiable), and the import ground: in regulated domains, part of your layer 1 is handed to you by the world — the skill is pruning it to the job, not authoring it.