Templates and contracts
Working Templates
Starter artifacts for workflow discovery, value, architecture, evaluation, security, release, adoption, handoff, and service operation.
Copy the smallest set needed for one workflow, replace the example values with evidence from the target environment, and keep the artifacts together under version control. A valid template is a structural starting point, not production evidence.
Engagement and value
| Template |
Decision it supports |
| Field-observation log |
What people actually do, including exceptions and workarounds |
| FDE discovery pack |
Whether the workflow is bounded, owned, verifiable, and ready |
| Workflow charter |
Whether to discover, pilot, defer, do not build, promote, pause, or retire the workflow |
| Value case |
Whether measured outcome improvement justifies full delivery and operating cost |
| Intelligence selection record |
Which rules, optimization, ML, retrieval, foundation-model, agent, and human options were considered for a consequential decision |
Solution and assurance
| Template |
Decision it supports |
| Operational ontology |
Which objects, states, rules, actions, permissions, and evidence define the domain |
| System-map manifest |
Which versioned software and operational relationships help navigation and impact review when system complexity justifies it |
| Change-impact assessment |
Which material-change impacts, owners, validation, review, rollout, and rollback evidence are required |
| Agent system |
Where deterministic software, model judgment, tools, people, state, and operations meet when an agent workflow is selected |
| Behavior bundle |
Which exact model-route, prompt, harness, context, tool membership, and guardrail bytes the agent uses |
| Tool contract |
Which data and effects a capability exposes and how it is authorized, contained, and verified |
| Capability manifest |
Which exact capability build is admitted, with what provenance, authority, assurance, and lifecycle |
| Threat model |
Which abuses and failures must be prevented, detected, recovered, and tested |
| Evaluation case |
Which representative condition must succeed, fail safely, or escalate |
| Evaluation report |
Which model- or agent-system claim was tested under which versions, trials, limits, and contamination controls |
| Handoff envelope |
What verified state, evidence, remaining work, authority, and budget one worker may pass to another |
| Architecture decision record |
Why a consequential design choice was accepted and how it can be reversed |
Executable support skeletons
| Skeleton |
Fail-closed role |
| Authorization policy |
Deny every request until an implementation supplies an explicit policy decision |
| Evaluation runner |
Refuse to claim an executed trial until a real runner replaces the skeleton |
| Evaluation world |
Represent the canonical template as not executed |
| Reference runtime |
Refuse workflow execution until an implementation replaces the skeleton |
| Operator surface |
Refuse to imply that an adoption plan is an implemented review interface |
| Operations bundle |
Refuse health, kill-switch, or rollback claims until controllers are wired |
Delivery and operation
| Template |
Decision it supports |
| Delivery and adoption plan |
How the vertical slice, acceptance, rollout, enablement, and ownership transfer will run |
| Solution release |
Which compatible model- or agent-system artifact bundle is approved for which segment and rollout |
| Customer enablement handoff |
Whether the receiving team can operate, change, recover, and retire the service |
| Production service review |
Whether to expand, constrain, pause, improve, or retire the live workflow |
| FDE and applied-AI portfolio review |
How to compare stage flow, accepted value, continuation, full delivery economics, reuse, and capacity across multiple workflows without overriding service gates |
| Field-learning register |
Which recurring field signal becomes a customer fix, platform change, documented pattern, or rejected proposal |
The current evaluation-report and solution-release JSON contracts are model/agent release profiles. A deterministic, optimization, or classical-ML-only system should use the target software release process with equivalent versioned data, model/code, policy, evaluation, operations, rollout, rollback, and ownership evidence; do not invent an agent system merely to satisfy these templates.
Follow the full sequence in the FDE playbooks. JSON artifacts declare a local schema and are checked by npm run validate.