Add a New Artifact Type

Adding a new artifact type is mostly a discipline exercise. The work succeeds when the synchronized definition set, the sanitized example Data Instance, the definition file, the example evidence, and the publication surface all describe the same thing.

Recommended Sequence

1. Start from the governing Document Role for the domain the artifact belongs to.
2. Confirm the shared Artifact Specification rules that govern how Artifact Definitions are authored and published.
3. Prepare the local orchestration payload with outputPath and sourceDefinitionPath; point sourceDefinitionPath at the source-side JSON context file you want embedded, and the Process side now resolves automatically to the single *.process.json contract.
4. Build or refresh the Process document so it can populate <artifactId>.definition.json inside outputPath. That local *.process.json file must consume the published Process questionnaire schema rather than inventing a per-source process schema. When the target questions are sequential, use one linear question flow that routes question to question until completion, and when the process branches, keep that branching inside the same *.process.json file through deterministic routing rules. Each question should use typed questions, explicit answer types from select-one, select-many, number, short-text, long-text, date, and percentage, conversation arrays composed of JSONL-style record objects, question-level for-ai, deterministic routing, and completed-conversation-to-output evaluation rules.
5. Build or refresh the Data Artifact Definition so the model contract is explicit about the fields an assistant or author must fill in.
6. Build or refresh the Template document so the concrete markdown-compliant template JSON stays aligned with the data contract, the published shared Template markdown schema, and the artifact purpose. Do not author a per-source Template schema.
7. Validate the generated bundle plus the definition file, then update the current files in place rather than creating version-suffixed variants.
8. Refresh from the latest standards registry at /standards/latest/index.json when a local cache needs the current public versions and download URLs.
9. Publish aligned examples and the public Artifact Definition page and downloads together so the route and bundle stay in sync.

What Good Looks Like

• The artifact type has a clear purpose that a reader can explain in one sentence.
• The synchronized bundle shares one artifact identity and one business purpose.
• The definitions tell a generator what belongs in each property, section, question output, or process field, not just what type it is.
• <artifactId>.definition.json inside outputPath points to the current bundle, including <artifactId>.data-example.json, preserves process-driven context, and embeds the parsed JSON copied from sourceDefinitionPath instead of leaving downstream tools to guess.
• The page visible to humans explains where the artifact fits in the public standards hierarchy.

Avoid

• Creating only one schema and inventing the Process or Template output later.
• Letting example documents override the governing Artifact Specification or Document Role Specification.
• Publishing examples that are “close enough” but not exact matches for the published schema identity.
• Replacing source-definition context or <artifactId>.definition.json inside outputPath when a field-preserving update is still credible.
• Mixing implementation guidance with normative contract text.