Resource map

What the resource graph is

The resource graph is a single navigation index across every product surface — lessons, exercises, learning paths, lab playbooks, lab templates, evaluation prompt sets, workflow kits, outcome pages, audience pages, guided demos, and the evidence workspaces that produce a decision brief or comparison URL. Each resource is tagged with a stage, an audience set, the goals it serves, and the evidence artifacts it helps produce. The /resources finder reads from this graph; nothing on it scores, sorts, or recommends a model.

The graph is pure local data. Titles and descriptions come from the underlying registries, so a rename inlessons.ts orworkflow-kits.ts flows through to the finder automatically. The stage / audience / goal / artifact tags live only inlib/resource-graph.ts — that file is the routing layer.

Learn → Apply → Verify → Test → Package

Every product surface lives at exactly one stage of the product loop. The graph lets the reader scan where the next step lives instead of guessing which hub to open.

1. Learn. Plain-language concept lessons, audience entry points, and role-based learning paths (/learn, /for, /learn/paths).
2. Apply. Exercises, the selection and comparison workspaces, and the guided demos that produce a working URL (/learn/exercises, /select, /compare/build, /demos).
3. Verify. Source freshness, lifecycle inspection, the reverification queue, and the coverage audit (/sources, /reverification, /coverage).
4. Test. Lab playbooks and evaluation prompt sets the reader runs in their own harness — the catalogue never calls live models on the reader's behalf (/lab, /lab/prompts).
5. Package. The decision brief, the Markdown templates, the workflow kits, and the outcome flows that ship a paste-ready artifact (/briefs/build, /lab/templates, /kits, /use-cases).

Resource types

The graph distinguishes thirteen resource types so the finder can filter precisely. Each type maps onto a single source registry:

• Lesson. Plain-language concept read from lib/lessons.ts.
• Exercise. Hands-on apply step from lib/learning-exercises.ts.
• Learning path. Sequenced lesson + exercise walk-through from lib/learning-paths.ts.
• Lab playbook. Structured testing recipe from lib/lab-playbooks.ts.
• Lab template. Paste-ready Markdown scaffold from the same registry.
• Evaluation prompt set. Generic, safe prompt sets from lib/evaluation-prompts.ts.
• Workflow kit. Packaged Markdown work document from lib/workflow-kits.ts.
• Outcome. Outcome-driven landing page from lib/outcome-use-cases.ts.
• Audience. Role-based entry page from lib/audiences.ts.
• Guided demo. Pre-packaged route plan from lib/guided-demos.ts.
• Workspace. Live builders (/select, /compare/build, /briefs/build).
• Evidence example. Worked output the reader can inspect before producing their own.
• Reference. The verification surfaces (/sources, /coverage, /reverification).

How to choose your next step

The finder supports six independent filters: audience, goal, stage, resource type, evidence artifact, and difficulty. Each filter is a GET link, no client state, no accounts. Combining filters is safe — the canonical URL stays /resources and any combination with a query string is noindex, follow.

Two common entry shapes:

• By role. Apply the audience filter — every resource tagged for that audience surfaces in stage order so the reader can walk Learn → Package without leaving the page.
• By artifact. Apply the artifact filter — the finder lists every resource that helps produce that specific Markdown output, so the reader walks straight to the package.

How audiences, outcomes, kits, and lab tools connect

Each audience entry page links to a role-based learning path, a workflow kit, and the outcome pages that match the audience's primary problem. Each outcome page lists the lessons, exercises, lab playbooks, prompt sets, and workflow kit that route the reader through Learn → Apply → Verify → Test → Package. Each kit packages the same resources as a single Markdown work document that the reader can paste into a PR, design doc, or review ticket.

The finder makes all of these reachable from one URL — but the underlying registries stay independent. Adding a new lesson updates the finder automatically. Removing a lesson drops it from the finder without breaking other registries.

What the platform does not decide

• Which model is best for the reader's workload. The catalogue never declares a winner.
• Which provider is cheapest or fastest. Pricing rows are references with retrievedAt dates; the platform does not rank by price or speed.
• Whether the integration meets the bar for production use. The workflow ends with an external test plan — running those tests is the team's responsibility.
• Whether the model is compliant for any regulatory regime. Governance pages name the questions to ask; the team's reviewers make the call.
• Whether a particular SEO outcome will follow from using the platform. The resource finder is a navigation aid, not a search-ranking guarantee.