How to Choose a Document Role

Choose the Document Role based on the artifact’s primary job. Start there before you select a specific Artifact Definition, because the role determines which governing rules apply and which member of the synchronized definition set you are shaping.

Use this decision rule

1. Choose Data when the artifact’s main job is to define the model contract for structured facts that need strong validation.
2. Choose Template when the artifact’s main job is to define the markdown-compliant view contract that turns validated data or other governed inputs into a human-readable output.
3. Choose Process when the artifact’s main job is to define the controller-style process contract that captures typed questions, answer types such as select-one, select-many, number, short-text, long-text, date, and percentage, conversation stored as a JSON array of JSONL-style record objects, and where completed user conversations are evaluated into normalized question outputs before routing continues.

Quick checks

• If the artifact is mostly a source of truth that other systems or templates consume, it is usually Data.
• If the artifact is mainly something a person reads, reviews, or shares as output, it is usually Template.
• If the artifact mainly captures process choices, typed question flows, prompts, or operational branching that later informs the current definition file context, it is usually Process.
• In the local orchestrated workflow, think of the bundle as MVC-like with one extra safety artifact: Data is the model, the sanitized example Data Instance shows a concrete non-PII instance, Template is the view, and Process is the controller-style process document built from typed questions, conversation stored as a JSON array of JSONL-style record objects, question-output evaluation guidance, and routing rules.

How to break ties

• Use the role that best describes the artifact’s primary outcome, not every secondary capability.
• If one file stores facts and another file renders those facts, treat the stored facts as Data and the rendered output contract as Template.
• If a document includes instructions but its main purpose is still to capture governed facts, keep it in Data.
• If a document triggers or coordinates work across steps, approvals, or tools, it belongs in Process even when it also carries some data.
• In the local CS2-build-artifact-definition orchestration flow, the Process output is always one *.process.json document; sequential targets should route question to question until completion, and branching targets should express that branching through deterministic routing rules inside the same document.

What to do next

1. Open the Document Role standards page to confirm the role-level rules.
2. Read the shared Artifact Specification to understand the authoring contract that all public Artifact Definitions follow.
3. Return to the Artifact Definitions catalog and choose the specific artifact type that fits your domain.
4. If you are using the synchronized local authoring workflow, prepare the orchestration payload with outputPath and sourceDefinitionPath before drafting.