Every artifact on this site appears twice below: once blank, with what goes in each field and how long it should be, and once filled from the worked example (the contractual due date and the payment cutoff, a medium-tier use case). The blank one is the template. Copy it, keep the field names, and keep the lengths short; a card that grows past one page stops being read.
The filled one shows the level of detail a team can act on; it is not meant to be copied. Numbers in the filled versions are illustrative.
Adapt before use: the named functions (risk, compliance, legal, privacy, security, internal audit) must tailor and approve each template for your organization before a team relies on it.
| Group | Templates |
|---|---|
| Intake and risk | 1 use-case intake card · 2 risk-tier checklist · 3 control crosswalk row |
| Team context | 4 team instructions file · 5 reusable prompt card · 6 hook specification |
| Reuse | 7 reuse decision record · 8 asset catalog entry |
| Program and decisions | 9 lab plan · 10 adoption scorecard · 11 tool evaluation decision record · 12 leader decision brief |
1. Use-case intake card
Answers: what is the use case, who owns it, what data does it touch, and which risk tier does it start in.
Blank
| Field | What goes here | Length |
|---|---|---|
| Name | Verb plus outcome | One line |
| Business owner | The accountable person by role | One line |
| Problem and baseline | What is slow, wrong or costly today, and how it is measured now | 2 sentences |
| What AI does | The task the AI performs, in plain words | 1 to 2 sentences |
| What humans decide | Every decision that stays with a person, and who | A short list |
| Data touched | Data classes in and out; any personal data; where it is processed | A short list |
| Tool and configuration | The approved tool and its approved configuration | One line |
| Proposed risk tier | Low, medium, high or prohibited, with the reason | 1 sentence |
| Success measure | The number that should move, its baseline and its owner | 1 sentence |
| Limits and fallback | Known failure modes and what happens when AI is unavailable or wrong | 2 to 3 items |
| Why AI | Why deterministic code or a process change is not enough | 1 sentence |
| Approvals | Who triages, who approves, by when | Roles and dates |
Filled: AI-assisted delivery of the due-date ask
| Field | AI-assisted delivery of the due-date ask |
|---|---|
| Name | Deliver one consistent due date and a zone-correct cutoff across four channels with AI-assisted drafting, coding and testing |
| Business owner | Payments product owner |
| Problem and baseline | Ten implementations (illustrative) show the due date differently; three convert it as an instant, so some West-coast customers see it one day early. Baseline: 40 related complaints a month (illustrative), owned by the contact-center lead |
| What AI does | Drafts stories, suggests catalog assets, proposes code changes and tests, drafts release notes; every output is a pull request or a document |
| What humans decide | Product owner accepts stories · developer reviews · a second engineer approves the merge · QA keeps or removes tests · release manager approves the release |
| Data touched | Proprietary source code (confidential); synthetic fixtures only; no customer personal data in prompts; processed in the approved region |
| Tool and configuration | Approved coding agent, enterprise configuration, admin-managed permissions; provider content retention and training disabled under contract; organization-controlled audit events and required traces retained under the records schedule, with sensitive content minimized |
| Proposed risk tier | Medium: coding assistant on proprietary source. The tier rates the AI use; the customer-facing change itself goes through existing change control and independent testing |
| Success measure | Due-date complaints down to under 5 a month (illustrative) within 60 days of release; owner: payments product owner |
| Limits and fallback | Model may miss temporal edge cases (covered by the evaluation set) · may write a new utility (covered by the reuse hook and CI rule) · if the tool is unavailable, the team works without it |
| Why AI | The fix itself is deterministic code; AI speeds the drafting and the test coverage, it does not compute dates |
| Approvals | Enablement lead triages (day 1) · security and data classification check (day 3) · business owner approves (day 5) |
2. Risk-tier checklist
Answers: which risk tier does this use case belong to, and what does that tier require before it starts.
Blank
| Field | What goes here | Length |
|---|---|---|
| Prohibited check | Does it make a fully automated adverse customer decision, or send restricted data to an unapproved tool? Yes stops here | Yes or no |
| Customer impact | Does AI output directly reach a customer, or determine or materially drive an outcome for one (money, credit, regulated disclosures)? Yes means High | Yes or no, one line why |
| Human verification | Does a trained human independently verify each consequential output before anyone acts on it? Internal decision support with this check is Medium; without it, High | Yes or no, who verifies |
| Money, credit, disclosure | Does it touch payments, credit, pricing or a regulated disclosure directly? | Yes or no, one line why |
| Data class | Highest data class the AI sees | One word plus source |
| Autonomy | Does AI only draft, or does it act in a system? | One line |
| Reversibility | How a wrong output is caught and undone | One line |
| Resulting tier | Low, medium, high or prohibited | One word plus reason |
| Required controls | What the tier adds, from the tier table | A short list |
| Sign-off | Who confirms the tier | Roles |
| Re-tier triggers | What would move it up a tier | 2 to 4 items |
Filled: AI-assisted delivery of the due-date ask
| Field | AI-assisted delivery of the due-date ask |
|---|---|
| Prohibited check | No. No customer decision; no restricted data leaves the approved tool |
| Customer impact | No direct reach. AI drafts code; customers see only code that humans reviewed, tested and released through existing customer-change controls |
| Human verification | Yes. A developer reviews and a second engineer approves every pull request; QA keeps or removes each generated test |
| Money, credit, disclosure | The change affects how a disclosed date is shown, but AI never computes the date; payment-schedule-service stays the source |
| Data class | Confidential (proprietary source); synthetic fixtures; no personal data |
| Autonomy | Drafts only. Every change is a pull request |
| Reversibility | Code review, CI (continuous integration) checks, the evaluation set and a feature flag; rollback by flag |
| Resulting tier | Medium: coding assistant on proprietary source |
| Required controls | Approved tool · data classification check · evaluation set for test generation · traces kept · named reviewer separate from the author |
| Sign-off | Enablement lead proposes · security confirms · AI risk partner notified |
| Re-tier triggers | AI writes customer-facing text directly · AI computes or stores dates · personal data needed in prompts · AI output used, merged or released without human verification |
3. Control crosswalk row
Answers: which existing control already covers this AI risk, what gap is left, and what evidence proves the added control works.
Blank
| Field | What goes here | Length |
|---|---|---|
| Domain | One crosswalk domain (inventory, privacy, validation, monitoring, change, and so on) | One line |
| AI risk | The failure mode in plain words | 1 sentence |
| Existing control | The control the organization already runs | 1 sentence |
| Gap | Why the existing control is not enough for AI output | 1 sentence |
| Added control | What is added, and whether it is preventive or detective | 1 to 2 sentences |
| Owner | Who runs the control (first line) | Role |
| Oversight | Who checks it (second line) and who audits it (third line) | Roles |
| Evidence | The record that proves it ran | One line |
| Frequency | Every change, daily, quarterly | One line |
Filled: validation of AI-generated date code
| Field | Validation of AI-generated date code |
|---|---|
| Domain | Validation |
| AI risk | A coding agent converts the date-only due date as an instant, so customers in western zones see the previous day |
| Existing control | Peer code review and unit tests on every change |
| Gap | The conversion looks correct in review, and tests the agent generates can share the same mistake |
| Added control | Preventive: CI rule blocks known instant conversions on date-only fields. Detective: a human-written evaluation set with midnight UTC (Coordinated Universal Time) and daylight-saving cases |
| Owner | Architecture owns the CI rule; payments QA lead owns the evaluation set |
| Oversight | Second line samples changes each quarter; internal audit tests the evidence chain once a year |
| Evidence | CI run log and evaluation report linked from the change record |
| Frequency | Every pull request; evaluation set re-run on any model change |
4. Team instructions file
Answers: what every coding agent on this team must know before it writes a line.
Blank
| Field | What goes here | Length |
|---|---|---|
| Header | Team, owner, review cadence, version | 2 lines |
| Domain rules | The rules a newcomer gets wrong, stated as do and never | 3 to 7 items |
| Reuse first | Where to search before writing new code, and how to record the decision | 2 to 3 items |
| Protected paths | Paths the agent must not edit, and who does | A short list |
| Data rules | What data may appear in prompts, tests and fixtures | 2 to 3 items |
| Commands | Build, test, lint | 3 lines |
| Output rules | The artifact every change lands as | 1 to 2 items |
| Escalation | When the agent must stop and ask a human | 1 to 2 items |
Filled: payments team
| Field | Payments team |
|---|---|
| Header | Payments team · owner: tech lead · reviewed quarterly and after any incident · v3 |
| Domain rules | The due date is date-only; never convert it · the cutoff is an instant shown in the customer's IANA (Internet Assigned Numbers Authority) zone from profile-service · missing zone: use the state-of-residence zone and label it · issued statements are immutable |
| Reuse first | Search the asset catalog before any date, time or calendar code · use shared-datetime · record reuse, extend or create in the reuse decision record |
| Protected paths | payment-schedule-service/ (its owners only) · ci/ (platform team only) |
| Data rules | No customer data in prompts or fixtures · use /test/fixtures synthetic accounts |
| Commands | make build · make test · make lint |
| Output rules | Every change is a pull request with a summary, the decision record and test results |
| Escalation | Stop and ask when a change touches the due date's source or a statement template |
5. Reusable prompt card
Answers: what task this prompt does, with what inputs, and how its output is checked before anyone uses it.
Blank
| Field | What goes here | Length |
|---|---|---|
| Name and version | Task name plus version | One line |
| Task | What the prompt produces | 1 sentence |
| Users | Roles that may use it | One line |
| Inputs | What the user pastes or attaches, and what must never be pasted | A short list |
| Prompt body | The instructions, kept in the repository | Linked file |
| Output format | The shape of the answer | One line |
| Check | How a human verifies the output before use | 1 to 2 items |
| Known limits | What it misses, from real runs | 2 to 3 items |
| Evaluation | The evaluation cases and the last result | One line |
| Owner and tier | Owner role; risk tier of the use | One line |
Filled: draft stories from an approved ask
| Field | Draft stories from an approved ask |
|---|---|
| Name and version | Draft stories from an approved ask · v1.2 |
| Task | Drafts one user story with 3 to 6 acceptance criteria per service that changes display |
| Users | Business analysts and product owners |
| Inputs | The approved ask, the impact analysis, the team instructions file · never customer records or complaint text |
| Prompt body | prompts/story-draft.md in the team repository |
| Output format | Markdown, one section per story, then open questions |
| Check | The BA (business analyst) checks every criterion against the temporal-domain contract; the product owner accepts in refinement |
| Known limits | Skips the missing-zone case unless reminded · invents a service when impact analysis is thin · writes criteria too long for one test |
| Evaluation | 3 sample asks, 18 expected criteria; last run found 16 (illustrative) |
| Owner and tier | Payments lead BA · medium |
6. Hook specification
Answers: when this hook runs, what it trusts, what it returns, what happens when it fails, and what it cannot catch.
Blank
| Field | What goes here | Length |
|---|---|---|
| Name and owner | Hook name; owning team | One line |
| Event | The agent event that triggers it (plan, before file write, before command) | One line |
| Scope | Paths, repositories or tasks it applies to | One line |
| Input | What the hook receives | One line |
| Trusted source | Where its answer comes from, and why that source is trusted | One line |
| Output schema | The fields it returns | One line |
| Timeout | Maximum run time | One line |
| Fail-open or fail-closed | What happens on error or timeout | One line |
| Bypass authority | Who may override it, and how | One line |
| False positives | How a wrong suggestion is reported and fixed | One line |
| Audit event | What is logged, where, for how long | One line |
| Enforcement point | The independent control that enforces the same rule | One line |
| Does not catch | Known blind spots | 2 to 3 items |
Filled: reuse advisory for date and time code
| Field | Reuse advisory for date and time code |
|---|---|
| Name and owner | reuse-advisory · architecture team |
| Event | Before file write, for new files only |
| Scope | Payments repositories; paths matching util, date or time |
| Input | Planned file path and the agent's one-line purpose |
| Trusted source | The governed asset catalog (owner-reviewed entries with status and version) |
| Output schema | candidates[] with asset, version, status, match reason, catalog link |
| Timeout | 3 seconds |
| Fail-open or fail-closed | Fail-open with a logged warning; it is advisory |
| Bypass authority | Developer may proceed; the reuse decision record must say why |
| False positives | Developer flags the suggestion; architecture triages weekly |
| Audit event | reuse.advisory.{suggested,accepted,declined} kept 1 year (illustrative) |
| Enforcement point | CI rule no-instant-on-date-only plus branch protection with required reviewers |
| Does not catch | A duplicate with an unrelated name · wrong logic with no banned pattern · code written outside the agent |
7. Reuse decision record
Answers: what was needed, what already existed, and why the team chose to reuse, extend or create.
Blank
| Field | What goes here | Length |
|---|---|---|
| Need | The capability required, in domain words | 1 sentence |
| Candidates found | Catalog assets considered, with version and status | A short list |
| Decision | Reuse, extend or create | One word |
| Rationale | Why this choice fits the need | 1 to 2 sentences |
| Asset and version | What the change depends on | One line |
| Evidence | Tests or examples that show fit | One line |
| Gaps raised | Catalog or asset issues found | One line |
| Exception | For create: owner, reason, expiry, compensating control | One line or none |
| Approver | Who approved the decision (not the author) | Role |
| Linked change | Pull request and change record | IDs |
Filled: due date and cutoff display
| Field | Due date and cutoff display |
|---|---|
| Need | Show a date-only due date unchanged, and a cutoff instant in the customer's zone with daylight-saving handled |
| Candidates found | shared-datetime 4.2 (supported) · a legacy date helper in web (deprecated) · two copies in notification-service (not catalogued) |
| Decision | Extend |
| Rationale | shared-datetime 4.2 supplies the date-only type (LocalDate) and instant plus zone formatting (formatInstant), but no labelled cutoff formatter. The team extends it upstream with the display-only formatPaymentCutoff(cutoffInstant, customerZone) instead of writing a local helper. payment-schedule-service alone computes the cutoff and exposes it as an instant; the library never calculates or overrides it |
| Asset and version | shared-datetime 4.2, plus the upstream display extension formatPaymentCutoff(cutoffInstant, customerZone) reviewed by the asset owner |
| Evidence | Evaluation set due-date-display v1 passes on all slices; contract tests pass: each channel's displayed cutoff equals the payment-schedule-service instant formatted in the customer zone, including the illustrative fictional non-business-day fixture |
| Gaps raised | The library lacked a labelled cutoff formatter (now the display extension); the catalog entry lacked a statement-rendering example; the two uncatalogued copies are flagged for retirement |
| Exception | None |
| Approver | Architect on the payments team |
| Linked change | Pull requests for web, mobile, statement-service, notification-service and the shared-datetime extension; change record CR-0000 (placeholder) |
8. Asset catalog entry
Answers: what this asset does, who owns it, how far it can be trusted, and where it should not be used.
Blank
| Field | What goes here | Length |
|---|---|---|
| Name | Asset name as imported | One line |
| Capability | What it does, in domain words, so a search finds it | 1 to 2 sentences |
| Owner | Owning team and support channel | One line |
| Versions | Supported versions and the recommended one | One line |
| Status | Supported, deprecated or retired, with date | One line |
| Assurance level | How it is tested and reviewed | One line |
| Limitations | Where it must not be used, or needs care | 2 to 3 items |
| Examples | Links to real usage | 2 to 3 links |
| Consumers | Teams using it | A count or list |
| Last reviewed | Date and reviewer | One line |
Filled: shared-datetime
| Field | shared-datetime |
|---|---|
| Name | shared-datetime |
| Capability | Date-only values that never shift, instants formatted in an IANA (Internet Assigned Numbers Authority) time zone, daylight-saving handling, and a business-calendar API. It formats cutoffs; payment-schedule-service alone computes them |
| Owner | Architecture platform team · support via the team's help channel |
| Versions | 4.x supported; 4.2 recommended; 3.x deprecated |
| Status | Supported since 2024 (illustrative) |
| Assurance level | Unit and property tests on every release; zone data updated each release; reviewed by architecture |
| Limitations | No labelled cutoff formatter in 4.2 (display-only extension formatPaymentCutoff(cutoffInstant, customerZone) proposed; never computes a cutoff) · business calendar covers the organization's holiday calendar only · does not choose a fallback zone; the caller must · not for historic dates before 1970 |
| Examples | Statement rendering · reminder notification cutoff · web due-date banner |
| Consumers | 7 teams / 31 repositories (illustrative) |
| Last reviewed | 2026-10 by the architecture lead |
9. Lab plan
Answers: what this lab will produce, for whom, under which data rules, and what evidence it leaves.
Blank
| Field | What goes here | Length |
|---|---|---|
| Lab | Lab number and name | One line |
| Goal | The artifact the lab produces | 1 sentence |
| Participants | Roles and count | One line |
| Facilitator | Who runs it | Role |
| When and how long | Date and duration | One line |
| Prerequisites | What must exist first | A short list |
| Environment | Tool, configuration and sandbox | One line |
| Data rules | What data is allowed | 1 to 2 items |
| Done when | The observable result | 1 to 2 items |
| Evidence kept | What is saved and where | One line |
| Follow-up | What happens after | One line |
Filled: L4 for the payments QA team
| Field | L4 test generation for the payments QA team |
|---|---|
| Lab | L4 · Test generation with an evaluation set |
| Goal | An evaluation set for due-date and cutoff display, and a scored agent run against it |
| Participants | 4 QA engineers and 1 developer (illustrative) |
| Facilitator | Payments QA lead, with the enablement lead |
| When and how long | One afternoon, 2 hours (illustrative) |
| Prerequisites | L1 instructions file merged · stories from L2 accepted · list of known hard cases |
| Environment | Approved coding agent, enterprise configuration, sandbox repository |
| Data rules | Synthetic fixtures only; no customer data or production logs |
| Done when | Evaluation set merged · run scored per slice · every generated test kept or removed by a QA engineer |
| Evidence kept | Evaluation report and run trace linked from the team's adoption scorecard |
| Follow-up | If thresholds pass two runs in a row, the team brings a leader decision brief for Stage 3 |
10. Adoption scorecard
Answers: how deep the team's adoption is, what value it produced, and whether quality and risk held.
Blank
| Field | What goes here | Length |
|---|---|---|
| Team and period | Team name; reporting window | One line |
| Stage by role | Current stage for each role | One line |
| Adoption | Active eligible users over eligible users | A ratio |
| Value | Net time saved, including review time, with method | One line |
| Quality | Rework rate; change failure rate; trend | One line |
| Risk | Near misses reported; policy findings; trend | One line |
| Evaluation | Pass rate per delegated task and slice | One line |
| Sustainability | Assets contributed or updated in the catalog | A count |
| Caveats | What the numbers cannot show | 1 to 2 items |
| Decision | Hold, move up, or step down, and who decides | One line |
Filled: payments team, last quarter
| Field | Payments team, last quarter (all numbers illustrative) |
|---|---|
| Team and period | Payments team · one quarter |
| Stage by role | Developer 2 · QA 2 (Stage 3 candidate for test generation) · BA 2 · PO 1 · release manager 1 |
| Adoption | 14 of 18 eligible users active weekly |
| Value | About 3 hours per developer per week net of review, from a two-week time study |
| Quality | Rework on date-related stories down from 22% to 9%; change failure rate flat |
| Risk | 6 near misses reported (all caught by CI); zero policy breaches; secret findings down |
| Evaluation | Test generation: 1.00 on date-only slice, 0.97 overall, two runs in a row |
| Sustainability | 3 assets contributed: instructions file, story prompt card, evaluation set |
| Caveats | Time saved is self-reported plus one study · more near-miss reports can mean better reporting, not more risk |
| Decision | Move QA test generation to Stage 3; engineering director decides via the leader decision brief |
11. Tool evaluation decision record
Answers: which tool was evaluated, against what, what it costs, how to leave it, and when this recommendation expires.
Blank
| Field | What goes here | Length |
|---|---|---|
| Decision asked | What is being decided, and for which use cases and tiers | 1 sentence |
| Requirements | Capabilities needed, stated without vendor names | 4 to 6 items |
| Gates | Security, privacy, legal and TPRM (third-party risk management) results | One line each |
| Benchmark | Representative tasks from the organization's own code | One line |
| Results | Scores per option on the benchmark | One line per option |
| Total cost | Licences, usage, admin, training, review time | One line |
| Integration | Identity, logging, CI, catalog, policy controls | One line |
| Portability and exit | How instructions, prompts and hooks move to another tool | One line |
| Provider change | How model or vendor changes are notified and handled | One line |
| Pilot | Who, how long, what was measured | One line |
| Recommendation | The choice and its conditions | 1 to 2 sentences |
| Expiry | When this must be re-decided | A date |
| Approvers | Roles that signed | Roles |
Filled: coding agent for engineering teams
| Field | Coding agent for engineering teams |
|---|---|
| Decision asked | Approve one coding agent for low and medium tier use on proprietary source |
| Requirements | Repository instructions file · reusable prompts · hooks at plan and write events · tool servers for the catalog · admin-managed permissions and models · background tasks that end in a pull request |
| Gates | Security: passed with permission lockdown · privacy: approved region; provider content retention and training disabled under contract; organization-controlled audit events and required traces retained under the records schedule, with sensitive content minimized · legal: IP (intellectual property) terms accepted · TPRM: approved with annual review |
| Benchmark | 30 tasks from the organization's own repositories, including the due-date fix (illustrative) |
| Results | Option A: 24 of 30 accepted after review · Option B: 21 of 30 (illustrative) |
| Total cost | Licences plus usage, about the cost of 0.5 engineer per 100 seats a year, plus review time (illustrative) |
| Integration | Single sign-on, audit log export, CI and branch protection unchanged, catalog via a tool server |
| Portability and exit | Instructions and prompts kept as plain markdown in the repository; hooks call shared scripts, not vendor features |
| Provider change | Vendor notice of model changes; the team re-runs evaluation sets before the new default is allowed |
| Pilot | 3 teams, 6 weeks; measured net time saved, rework, near misses (illustrative) |
| Recommendation | Approve Option A for low and medium tiers; high tier stays out of scope until a separate review |
| Expiry | 12 months, or earlier on a material change |
| Approvers | Engineering leadership · security · privacy · TPRM · AI risk partner |
12. Leader decision brief
Answers: what decision the leader is asked to make, on what evidence, with which risks, and what would reverse it.
Blank
| Field | What goes here | Length |
|---|---|---|
| Decision | The decision in one sentence | 1 sentence |
| Context | Where the team is today and why now | 2 sentences |
| Evidence | The exit evidence for the current stage | 3 to 5 items |
| Options | Two or three options, including do nothing | One line each |
| Recommendation | The option and its conditions | 1 to 2 sentences |
| Risks and controls | Main risks and the control for each | 2 to 4 items |
| Cost | Time, money, reviewer capacity | One line |
| Step-down triggers | What would move the team back a stage | 2 to 4 items |
| Ask of the leader | Exactly what the leader signs or provides | 1 sentence |
| Decide by | Date and decision owner | One line |
Filled: payments team from Stage 2 to Stage 3 for test generation
| Field | Payments team from Stage 2 to Stage 3 for test generation |
|---|---|
| Decision | Let the payments QA team delegate test generation to a coding agent, with output always a pull request a QA engineer reviews |
| Context | The team has run at Stage 2 for one quarter with an instructions file, prompt cards and the reuse hook. Test generation is the slowest step in the due-date work |
| Evidence | Evaluation set passes 1.00 on date-only and 0.97 overall, two runs in a row (illustrative) · traces kept for every run · rework on date stories down from 22% to 9% (illustrative) · reviewer capacity confirmed |
| Options | Stay at Stage 2 · move test generation only to Stage 3 · move all QA tasks to Stage 3 |
| Recommendation | Move test generation only; other QA tasks stay at Stage 2 until each has its own evaluation set |
| Risks and controls | Tests mirror code blind spots: human-written evaluation set · reviewer fatigue: cap of 20 generated tests per pull request (illustrative) · model change: re-run the evaluation before the new default |
| Cost | No new licences; about 4 hours a week of QA lead time for evaluation upkeep (illustrative) |
| Step-down triggers | Evaluation below threshold on any slice · a model or provider change · an escaped date defect · a control gap found by second line |
| Ask of the leader | Approve the move and protect the QA lead's evaluation time for two quarters |
| Decide by | End of the month · engineering director, with the AI risk partner consulted |