The Toolkit Is the Approach
The artifact isn’t a PDF you download and fill out. It’s a method. Bring the documents that already describe the work — and a skilled AI builds your complete tollgate submission package from them in minutes.
The problem with template libraries
A folder of blank templates is homework. Most practitioners don’t have time to manually populate a Charter, write a CBA from scratch, and fill out an Intake Form from a blank page — especially when the information that belongs in those documents already exists somewhere: a SOW, a kickoff transcript, a vendor proposal, a budget request, a slide deck. The toolkit approach reads what you have and builds the submission from it.
What to bring
Drop in any combination of these. The more you have, the better the output. You are never blocked by what’s missing — gaps are surfaced explicitly so nothing gets buried.
Transcribed discussions and meeting notes are especially valuable. The information is almost always there — it just hasn’t been organized into a decision-ready structure yet. Bring everything. The AI does not need a finished document — it needs the raw material your project has already produced. The more context it has, the fewer gaps in the output.
What comes out
Five documents that constitute a complete Waypoint tollgate submission package. Every field is populated from your source materials. Inferences are labeled as inferences. Gaps are listed explicitly in a Gap Summary. Nothing is invented.
After the five documents, you get a Submission Readiness Summary: fields populated from source documents, fields requiring submitter input, any domain screening items blocking completion, and an overall readiness assessment — Ready for review / Needs submitter input / Blocked, do not advance.
Waypoint Intake Builder — Claude Skill
The skill runs inside Claude desktop with Cowork mode. Drop in your documents, say “build my intake package” or “prep this for tollgate,” and it builds the five-document submission from what you provide. Install once. Use on any project. Any capable AI can produce the same output — give it your documents and ask it to populate the Waypoint intake package structure.
Download the Skill →Where does the data live?
The intake builder produces five populated documents. Those documents need a home — somewhere they can be stored, retrieved, updated, and acted on over time. Waypoint does not prescribe a tool. The structure is the standard. The container is yours.
Any environment that holds structured data consistently works: a spreadsheet, a project tracking system, a document platform, a set of maintained files in a shared drive. The right answer is whichever one your organization will actually keep current. A sophisticated system nobody updates is worse than a spreadsheet everybody trusts.
For practitioners who have made the AI-native shift
If you have an MCP connection from your project data source — Jira, ServiceNow, Planview, a well-maintained spreadsheet — into Claude, the copy-paste step disappears. The AI reads live data from your system, builds the governance views on demand, and flags what is missing or off-track. The container becomes the source of truth. Claude becomes the interface that makes it governable. That is not a future state. It is available now to any practitioner who has the connection set up and knows what to ask.
The 36 artifact standards — reference map
The artifact library covers every governance document in the framework across all 12 steps. These are the field-by-field standards — what each document must contain and why. Use the copy-paste prompts on each page to build the real artifact from your actual project materials. The tables are the standard the output gets measured against.
Which documents each phase uses
The 36 artifact standards group into five phases of the governance lifecycle. Every document has a home phase and the steps it serves. The numbers (T1–T36) are stable catalog IDs — a library index, not a running order — so they are not expected to match the step sequence. A few artifacts, marked ⇆, are reused in later steps.
Minimum Viable Governance by Portfolio Size
Not every organization needs all 36 artifacts running from day one. The framework scales by portfolio size and cycle volume — some artifacts are load-bearing at any scale, others earn their place once volume or complexity makes the informal version unreliable. Forcing a three-person EPMO standing up its first tollgate to run the full 36-artifact library on day one is how governance frameworks get abandoned for being “too heavy.” Skipping the load-bearing dozen because “we’re too small for process” is how the same abandonment happens from the other direction.
Tier 1 — Micro (roughly under 15 active initiatives)
Run the twelve load-bearing artifacts and nothing else. These are the ones no governance model functions without, regardless of scale — they define the front door, the decision, the record, and the close.
| Artifact | Why it’s load-bearing |
|---|---|
| T1 — Intake Form | Defines the front door. No front door, no portfolio view. |
| T2 — Cost-Benefit Analysis | The minimum case for any investment decision, at any scale. |
| T3 — Authorization Checklist | The eight confirmations that separate a decision from a hallway conversation. |
| T5 — Tollgate Decision Record | Without it, no record survives the meeting that produced it. |
| T12 — Portfolio Inventory | You cannot govern what you cannot list. |
| T16 — Minimum Information Standard | Sets the intake bar. Without it, “minimum viable governance” has no floor. |
| T17 — Problem Statement | The most common root cause of failed initiatives is skipping this. |
| T19 — Outcome Definition Worksheet | Defines what success means before work starts, at any scale. |
| T23 — Decision Agenda | Structures the tollgate meeting itself — without it, decisions drift. |
| T26 — RAID Standard | Risk visibility does not become optional because the portfolio is small. |
| T32 — Post-Investment Review | Closing the loop is what makes the next cycle’s decisions better. |
| T36 — Assumption Log | Pairs directly with T2 — tracks which assumptions held. |
Tier 2 — Mid-Size (roughly 15–75 active initiatives)
Add these twenty once volume makes the informal version unreliable — when priorities compete for the same capacity, when benefit tracking needs to roll up across projects, or when the tollgate agenda has more than a handful of items per cycle.
| Artifact | What breaks without it, at this scale |
|---|---|
| T4 — Benefits Register | Informal benefit tracking stops rolling up once several projects report simultaneously. |
| T6 — Prioritization Scoring Model | “Prioritize by conversation” breaks once proposals outnumber capacity. |
| T7 — Health vs. Value Review | Portfolio-level health checks need a repeatable structure once there are too many projects to hold in one person’s head. |
| T8 — Governance Retrospective | Needs enough completed cycles to retrospect on. |
| T13 — Classification Rules | Manual triage stops being consistent once intake volume grows. |
| T14 — Missing Information Log | Tracking gaps by memory fails once submission volume increases. |
| T15 — Intake Routing Guide | Routing by whoever’s available stops scaling with volume. |
| T18 — Assumptions Log | Problem-definition assumptions need separate tracking once more than one team defines problems in parallel. |
| T20 — Benefit Owner Register | Ownership needs a durable record once benefits are tracked across a real portfolio. |
| T21 — Weighting Guidance | Scoring weights need documented rationale once more than one person applies them. |
| T22 — Prioritization Tradeoff Summary | Trade-off visibility matters once real contention for capacity exists. |
| T24 — Sponsor Briefing | Standardized sponsor prep earns its place once tollgate volume rises. |
| T25 — Capacity Impact Summary | Eyeballing capacity impact stops working once concurrent projects multiply. |
| T27 — Decision Escalation Format | Ad hoc escalation breaks down once decision volume rises. |
| T28 — Dependency Map | Dependencies become untrackable by memory past a handful of concurrent projects. |
| T29 — Capacity View | A shared capacity view earns its place once resourcing conflicts appear. |
| T30 — Portfolio Tradeoff Summary | Needed once portfolio-level trade-offs become routine, not exceptional. |
| T31 — Adoption Measurement Framework | Adoption tracking needs structure once more than one initiative drives change concurrently. |
| T34 — Process Improvement Backlog | A backlog is only meaningful once there is a recurring process to improve. |
| T35 — Portfolio Change Saturation Register | Saturation risk isn’t real until concurrent change volume is high enough to create it. |
Tier 3 — Enterprise (roughly 75+ active initiatives, or a formal maturity mandate)
Add these four when the governance function itself needs to demonstrate maturity — to an audit, a board, or a maturity assessment — or when the discovery work of standing up or relaunching the governance model is underway.
| Artifact | When it earns its place |
|---|---|
| T9 — Stakeholder Interview Guide | Used once, during the Step 1 listening tour that builds or relaunches the governance model — not a recurring operational artifact. |
| T10 — Current-State Decision Map | Same — a Step 1 discovery artifact, not steady-state overhead. |
| T11 — Influence Map | Same — built once at model design, referenced afterward. |
| T33 — Maturity Evidence Checklist | Only relevant once you are formally demonstrating governance maturity to an external party. |