Describe the system behind each release

Learning objective

Document context, components, data flows, trust boundaries, external dependencies, and the versioned prompt, model, tool, and evaluation configuration.

Core idea

For an architect handing a Claude system to another team, documentation must identify both the system’s structure and the configuration that produces its behavior. A component picture cannot tell an operator which prompt generated a disputed answer. A prompt inventory cannot show where an unauthorized document entered the workflow. You need both views tied to a release.

Use an architecture description with a release inventory as its entry point. NIST AI RMF’s MAP 1.1 calls for documented purposes, deployment context, assumptions, and limitations; MAP 2.2 covers knowledge limits and human oversight. Apply those categories to concrete flows and artifacts. The inventory format here is an application convention, not an Anthropic API resource.

How it works

Describe context before internals

Start with who uses the service, the business task it supports, and the effects it may produce. State excluded uses, external actors, human decision points, and the business constraint that matters most. “Answers support questions” is insufficient if some answers become refund requests and others remain drafts.

Then describe the components responsible for identity, request orchestration, Claude calls, retrieval, tool execution, human review, and storage. Give each component an owner and an interface reference. Separate a logical component from a deployment unit: two functions in one service can still have different authorization responsibilities. Readers must be able to locate the enforcement code without guessing from a box labeled “agent.”

Label flows and crossings

Maintain a flow register alongside the component view. Each row names its source, destination, payload class, initiating identity, authorization check, storage destination, and failure behavior. Include the paths to logs and evaluation datasets; these copies can cross a different boundary from the serving request.

For example, a support transcript can move from an authenticated application into a Claude request, while a retrieved article arrives from a separately maintained index. Neither the transcript’s instructions nor the article’s contents acquire the application’s authority. Anthropic’s tool-call guidance explicitly treats external content in tool results as untrusted and keeps it inside tool_result blocks rather than promoting it into system instructions.

Record the control at each trust boundary: where identity is verified, where a tenant filter is applied, where an action is authorized, and where sensitive content is removed from an operational record. A line labeled “secure” supplies none of those answers. The register points to the implementation contract; 6.4.3 owns how to write that contract.

Inventory behavioral configuration

Store the configuration references with the release rather than describing them as “the approved prompt” or “the production model.” A useful inventory includes these entries:

Anthropic documents name, description, and input_schema as user-defined tool-definition fields. Version the descriptions as well as the schemas: a description influences tool selection even when the handler’s interface is unchanged. Keep the handler revision because a stable schema can hide a changed side effect.

For Claude model IDs, Anthropic guarantees a fixed model version for the lifetime of the ID. On the Claude API, convenience aliases for models before the 4.6 generation resolve to the most recent dated snapshot for that minor version; recording an alias does not pin the model. Canonical dateless IDs from the 4.6 generation onward identify fixed snapshots and are pinned. Also record the serving platform; a release description must identify the actual target the integration sends.

Pinning is necessary for attribution but does not promise identical outputs. Anthropic notes that serving infrastructure, including routing and safety classifiers, can change while model weights remain fixed. Preserve evaluation results and production observations rather than treating a stable ID as proof that behavior cannot drift.

Keep the description usable after release

Give the release one inventory revision that resolves to all these artifacts. When a prompt, tool, model target, or evaluation rubric changes, review the affected flow and inventory entries together. Require a corresponding evaluation result before approving the changed configuration. Anthropic’s evaluation guidance supports explicit, measurable, multidimensional success criteria; it does not provide your release-inventory storage system.

Keep secret values out of the inventory. Record the owning secret reference and identity relationship, so reviewers understand the dependency without receiving credentials. For external services, include their owner, interface version, operational dependency, and the behavior when unavailable. NIST GOVERN 6.2 calls for contingency processes for failures in high-risk third-party systems.

Key distinctions and trade-offs

Context versus components: Context explains users, purpose, and outside systems. Components explain responsibilities inside the service. Combining them into an unreadable deployment drawing hides both.

Data flow versus trust boundary: A flow says what moves. A trust boundary says where assumptions about identity, authority, or content must change. One flow can cross several boundaries.

Release inventory versus execution record: The inventory defines the approved configuration. A per-run record identifies the configuration actually used; see 4.6.1. Both must resolve to the same versions for incident reconstruction.

Detailed documentation costs review time. Prioritize boundaries, side effects, and independently changing configuration over exhaustive descriptions of every helper function. An architecture description earns its maintenance cost when another team can locate the relevant implementation and owner.

Architecture / decision scenario

A retailer transfers its support assistant to a six-person delivery team. It handles 8,000 conversations daily and must keep customers from seeing another tenant’s order data. The proposed handoff is a deployment picture and a link to the main branch. That is attractive because it takes one afternoon, but the main branch changes daily while a production release can remain active for two weeks.

The architect instead requires a release-specific inventory, a component responsibility view, and a flow register. The register traces customer identity through the tenant-filtered order lookup, marks retrieved product text as untrusted, and shows which redacted fields enter telemetry. External order-service availability has a named owner and a documented unavailable outcome.

The release inventory resolves the prompt, model target, tool definitions and handlers, retrieval revision, and evaluation configuration. The quality owner attaches the evaluated cross-tenant cases and acceptance result. A later prompt-only change therefore creates a reviewable configuration revision rather than silently changing what the diagram claims. The delivery lead accepts maintenance ownership; the architect can explain both where data travels and which behavior was approved.

Common exam traps

• Handing over a component drawing without identities, payload classes, or enforcement points.
• Treating prompt text or tool descriptions as unversioned documentation.
• Recording a model family instead of the deployed target and platform.
• Assuming a fixed model ID guarantees identical behavior indefinitely.
• Naming an evaluation suite without its dataset, rubric, thresholds, and result revisions.

What to remember

Document the context, component responsibilities, and classified flows, then tie their behavioral configuration to a release. Make every crossing and dependency inspectable. Another team should identify the deployed prompt, model target, tools, evaluation result, and owner without consulting the original architect.

Knowledge check

References

• NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• Anthropic, Handle tool calls
• Anthropic, Define tools
• Anthropic, Model IDs and versioning
• Anthropic, Define success criteria and build evaluations