The ASD Method & Artifact Catalog

Method Library by Phase

The method library follows the six-phase practice loop rather than a grab bag of prompts. That matters. A researcher should not have to guess whether a method is meant to generate evidence, cluster it, turn it into concepts, or carry it into delivery. The counts are fixed: research 19, synthesis 15, ideation 13, prototyping 12, delivery 10, measurement 11. Together they total the 80 shipped skills exposed by the CLI, MCP server, host packs, and Studio adapter.

The more subtle count is the source count. The repository holds 81 SKILL.md sources because the compiler keeps both the generated and the authored forms for one method, then resolves them with a flagship-wins rule. The method that gets that treatment is service-blueprinting. I am calling it out because it signals what deserves hand-authored depth in this platform: the work that most often collapses into diagram cosmetics unless the instructions are unusually explicit about lanes, waits, failures, handoffs, and evidence discipline.

Research (19). The research phase is narrower than many teams expect. It is not a vague “discovery” bucket. It is the part of the system that builds trustworthy evidence, plans the next evidence capture, and denies unsupported claims before they leak forward. Most methods here write insight-set or research-plan outputs because the runtime wants the evidence register to stay legible.

Synthesis (15). Synthesis is where the platform becomes opinionated. It does not treat clustering, personas, journeys, and blueprints as presentation choices. Each one is a separate contract with different minimums, different owner roles, and different failure modes. This is also where the flagship authored skill sits, because blueprinting is the moment sloppy teams start inventing process steps they cannot cite.

Ideation (13). The ideation phase is narrower than an innovation theatre workshop. ASD only keeps methods that can preserve traceability back to evidence or forward to a typed artifact. That is why wild idea generation sits next to scoring, canvas work, and concept briefs inside one bounded set.

Prototyping (12). ASD treats prototyping as service rehearsal and evidence production, not UI polish. Several methods here produce test-report or decision-matrix outputs rather than a new concept artifact. That is deliberate. The goal is to learn, narrow, and either move forward or kill a weak idea without lying about the evidence.

Delivery (10). Delivery is where the method system stops flattering speculative work. Everything here assumes a design artifact already exists and now has to become a rollout plan, standard, queue decision, or future-state operating logic. The methods are fewer because they are downstream of earlier proof.

Measurement (11). Measurement closes the loop. Some methods here audit the lived experience. Others connect service change to KPI structure, maturity, recovery, or profit-chain logic. None of them are decorative. If I cannot point to a measurable service consequence, ASD assumes I am still describing intent, not performance.

Artifact Vocabulary: Canonical, Alias, Pending

The vocabulary catalog has 39 rows, but they do not all mean the same thing. This is the trap I see readers fall into first. A familiar label in the catalog is not automatically a live runtime kind. The catalog deliberately mixes three statuses: 18 canonical labels that name shipped runtime kinds, 13 aliases that keep practitioner language alive without multiplying schemas, and 8 pending concepts that remain vocabulary only until registry, template, renderer, and skill gates exist.

That split is healthy. Teams speak in aliases all the time. They say “insight register” instead of insight-set, “standards audit” instead of service-standard-set, and “storyboard walkthrough” instead of storyboard. ASD lets the language survive in the catalog while keeping the runtime set small enough to reason about. Pending rows stay visible so I can talk about future platform scope without pretending it already runs.

Registered Runtime Kinds

The runtime registry contains 38 artifact-kind contracts. That is the number the engine can persist, export, and look up through schema metadata today. I state it this way because the registry is not the same thing as the 39-row vocabulary. The clean mental model is this: 18 catalog rows are canonical and executable, 13 catalog rows are aliases that collapse onto existing executable kinds, 8 rows are still pending, and 10 runtime kinds exist only in the registry because they are operationally useful without being part of the public template promise.

Those ten registry-only kinds are actor-network-map, change-plan, day-in-the-life, expectation-map, raci-matrix, roadmap, service-profit-chain, service-scenario, touchpoint-inventory, and walkthrough-script. They are real runtime contracts. They are simply outside the 39-row practice-catalog claim. That is why the arithmetic feels strange until you separate vocabulary from execution.

Authored Templates

The authored template tier is deliberately small: seven fillable forms, each backed by a Markdown source in platform/templates/ and a runtime-aware metadata record in suite/packages/knowledge/data/templates/. These are the forms I can hand to a human team before any agent touches the project. They are also the templates most likely to survive a workshop and still compile into useful runtime artifacts later.

That seven-template set is intentional. ASD is not promising a fillable form for every vocabulary row. It is promising depth where teams repeatedly need scaffolding: stakeholders, ecosystems, insights, personas, journeys, blueprints, and jobs. Everything else must earn authored-template status through the same contract discipline as a new runtime kind.

The Admin Record: review-veto-log

review-veto-log is the cleanest example of the platform’s governance posture. It is a registered runtime kind, it is canonical in the vocabulary, and it is intentionally administrative. Users do not fill it out as a workshop artifact. The Critic writes it when a review happens. That distinction matters because the log is the memory of why a pass was granted or a veto was issued, and the rest of the pipeline can replay it without guessing.

The record is always final from birth. That is the point. A veto log that can drift in and out of draft state would be governance theatre. Instead, sd_review appends rows across verdicts, keeps row numbering stable, links the log back to the reviewed artifact through reviewOf, and enforces the basic discipline: a veto needs at least one defect row with a fix, a pass cannot smuggle in defect rows, and a pass must cite evidence in at least one proposal row.

{
  "kind": "review-veto-log",
  "status": "final",
  "reviewOf": "7f9fefdc44f5469195106e739112f9ae",
  "nodes": [
    {
      "id": "r1",
      "label": "All three nodes cite zero evidence rows; the acceptance gate cannot pass until every node cites the register",
      "fields": {
        "rowKind": "defect",
        "severity": "high",
        "rule": "min-evidence-per-node",
        "message": "All three nodes cite zero evidence rows; the acceptance gate cannot pass until every node cites the register",
        "fix": "Re-derive each node from the register with verbatim quotes attached"
      }
    }
  ]
}

If I had to reduce this appendix to one sentence, it would be this: ASD is strict about names because names decide what can be executed, what can be reviewed, and what remains honest future scope. The method count, the vocabulary count, the runtime-kind count, and the template count are all true at the same time once you stop forcing them to mean the same thing.