This document defines the Process Document Role v1.0.0 as the governing Document Role for the Workflow domain. Artifact Definitions classified into this domain MUST conform to both this Document Role and the shared Artifact Specification.
\nThe v1 process model remains intentionally small:
\nProcess Artifact Definitions authored under this Document Role MAY describe complex standard operating procedures and business processes, but they MUST do so with explicit typed structures and deterministic section-inclusion rules rather than ambiguous narrative branching.
\nThis release is a hardening patch over v1.0.0. It corrects support-artifact schema handling, sharpens conformance language, makes the feed derivation rules more deterministic, aligns diagnostics with RFC 6901 JSON Pointer semantics, and expands the conformance fixture set so every public rule identifier is exercised by at least one published fixture.
\nThis document is a stable public normative publication for the v1 process contract published at https://www.cuddler.dev/standards/document-role/process/.
This versioned Document Role is intentionally self-contained. It includes the full normative contract for release 1.0.0, and no linked schema, manifest, example, or support file is required in order to understand the required behavior defined here.
The primary normative contribution is the core process contract made of:
\ncatalog.manifest.jsonworkflow.manifest.json*.process.jsonThe rest of the release is organized as supporting material around that core:
\nfeed.jsonplugin.manifest.json, skill.manifest.json, exec.workflow.jsonThis Document Role defines:
feed.json,This Document Role does not standardize:
\nThe key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 (RFC 2119 and RFC 8174) when, and only when, they appear in all capitals.
This specification defines the following formal conformance classes:
\nfeed.json from valid source artifacts.These are the only formal conformance classes for v1.0.0.
\nThis release also publishes informative profiles that are useful but are not themselves formal conformance classes:
\nplugin.manifest.json, skill.manifest.json, or exec.workflow.json.Those profiles are published for tooling guidance and fixture discovery. They are not substitutes for the formal conformance classes above.
\nA conforming Cuddler process Artifact Definition MUST:
\nfor-ai Alpaca arrays for every instance-visible property, either directly or through a reused definition,select-one, select-many, number, short-text, long-text, date, and percentage, conversation stored as a JSON array of JSONL-style record objects, question-level for-ai evaluation guidance, and deterministic next-question routing whenever a workflow step uses one *.process.json document as its typed question contract,specification.index.json,$id values for the release.A conforming process data file MUST:
\n$schema value for its artifact type,A conforming validator MUST:
\ndiagnostics.schema.json,ruleId values for every public failure condition,A conforming publisher MUST:
\npublishedOnUtc values in UTC with a trailing Z when the publisher is the system generating those values,feed.json according to Section 14.The following references are normative for this specification:
\nRFC 2119, Key words for use in RFCs to Indicate Requirement LevelsRFC 8174, Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 3986, Uniform Resource Identifier (URI): Generic SyntaxRFC 6570, URI TemplateRFC 6901, JavaScript Object Notation (JSON) PointerRFC 7763, The text/markdown Media Typehttps://semver.org/RFC 3339, Date and Time on the Internet: TimestampsRFC 3552, Guidelines for Writing RFC Text on Security ConsiderationsWhere this specification restricts a referenced standard to a narrower authoring profile, the narrower Cuddler rule governs within this contract.
\nThe design goals of v1 are:
\nThe non-goals of v1 are:
\nThis Document Role uses Process Document Role as the public contract name.
\nThe legacy https://www.cuddler.dev/standards/document-role/process/v1.0.0/... namespace remains the canonical identifier namespace only for the published instance-validation schemas retained for compatibility in the v1 line:
catalog.manifest.schema.jsonworkflow.manifest.schema.jsonquestionnaire.schema.jsonplugin.manifest.schema.jsonskill.manifest.schema.jsonexec.workflow.schema.jsonfeed.schema.jsonSupport-artifact schemas published for v1.0.0 use Cuddler-hosted schema identifiers under https://www.cuddler.dev/standards/document-role/process/.
Public prose, release pages, and examples MUST use Cuddler naming. The retained legacy namespace MUST NOT be interpreted as a competing product identity.
\nThe v1 core process contract consists of three required data-file types:
\ncatalog.manifest.jsonworkflow.manifest.json*.process.jsonTheir relationship is fixed:
\nComplex procedures, approval paths, exception routes, escalation rules, and evidence requirements MAY be represented by Artifact Definitions in this domain, but any such structure MUST be modeled through deterministic typed fields, ordered collections, and explicit conditional gates anchored in the catalog-to-workflow-to-step relationship.
\nThe core contract does not require:
\nThis conceptual core MUST remain stable throughout the v1 line.
\nThe minimum authored source surface for a valid process family is:
\ncatalog.manifest.jsonworkflow.manifest.json*.process.jsonThe following surfaces are companion profiles rather than part of the minimum authored source surface:
\nfeed.json as the publication profileplugin.manifest.json as an adjunct package profileskill.manifest.json as an adjunct package profileexec.workflow.json as an adjunct package profileThose artifacts are optional for core source validity and do not add normative requirements beyond the ones stated in this document.
\nThe canonical source layout for one catalog is:
\ncatalogs/<catalog-id>/\n catalog.manifest.json\n plugin.manifest.json # optional adjunct\n skill.manifest.json # optional adjunct\n exec.workflow.json # optional adjunct\n <workflow-id>/\n workflow.manifest.json\n <step-id>.process.json\n <step-id>/script.ps1 # optional\nAll manifest path references in v1.0.0 MUST use the catalog-root-relative reference frame.
\nThat means every referenced path is resolved relative to the directory that contains catalog.manifest.json.
The machine-readable artifact registry for this release is published as specification.index.json.
The normative instance-validation artifact mapping is:
\n| Artifact type | \nCanonical schema $id | \nRepo source path | \nPublic download URL | \nInstance files validated | \n
|---|---|---|---|---|
| Catalog manifest schema | \nhttps://www.cuddler.dev/standards/document-role/process/v1.0.0/catalog.manifest.schema.json | \ntests/fixtures/document-role-specifications/process-document-role-specification/1.0.0/support/catalog.manifest.schema.json | \nhttps://www.cuddler.dev/standards/document-role/process/v1.0.0/catalog.manifest.schema.json | \ncatalog.manifest.json | \n
| Workflow manifest schema | \nhttps://www.cuddler.dev/standards/document-role/process/v1.0.0/workflow.manifest.schema.json | \ntests/fixtures/document-role-specifications/process-document-role-specification/1.0.0/support/workflow.manifest.schema.json | \nhttps://www.cuddler.dev/standards/document-role/process/v1.0.0/workflow.manifest.schema.json | \nworkflow.manifest.json | \n
| Questionnaire schema | \nhttps://www.cuddler.dev/standards/document-role/process/v1.0.0/questionnaire.schema.json | \ntests/fixtures/document-role-specifications/process-document-role-specification/1.0.0/support/questionnaire.schema.json | \nhttps://www.cuddler.dev/standards/document-role/process/v1.0.0/questionnaire.schema.json | \n*.process.json | \n
| Plugin manifest schema | \nhttps://www.cuddler.dev/standards/document-role/process/v1.0.0/plugin.manifest.schema.json | \ntests/fixtures/document-role-specifications/process-document-role-specification/1.0.0/support/plugin.manifest.schema.json | \nhttps://www.cuddler.dev/standards/document-role/process/v1.0.0/plugin.manifest.schema.json | \nplugin.manifest.json | \n
| Skill manifest schema | \nhttps://www.cuddler.dev/standards/document-role/process/v1.0.0/skill.manifest.schema.json | \ntests/fixtures/document-role-specifications/process-document-role-specification/1.0.0/support/skill.manifest.schema.json | \nhttps://www.cuddler.dev/standards/document-role/process/v1.0.0/skill.manifest.schema.json | \nskill.manifest.json | \n
| Exec workflow schema | \nhttps://www.cuddler.dev/standards/document-role/process/v1.0.0/exec.workflow.schema.json | \ntests/fixtures/document-role-specifications/process-document-role-specification/1.0.0/support/exec.workflow.schema.json | \nhttps://www.cuddler.dev/standards/document-role/process/v1.0.0/exec.workflow.schema.json | \nexec.workflow.json | \n
| Feed schema | \nhttps://www.cuddler.dev/standards/document-role/process/v1.0.0/feed.schema.json | \ntests/fixtures/document-role-specifications/process-document-role-specification/1.0.0/support/feed.schema.json | \nhttps://www.cuddler.dev/standards/document-role/process/v1.0.0/feed.schema.json | \nfeed.json | \n
Support-artifact schemas and manifests are also normative release artifacts and are listed in specification.index.json.
specification.index.json is a machine-readable registry for the release package. It supports tooling and publication workflows, but the normative contract remains fully stated in this document.
Catalog ids, workflow ids, step ids, questionnaire ids, and publication asset ids MUST:
\n^[a-z][a-z0-9]*(?:-[a-z0-9]+)*$,questionnaireId MUST equal the owning step id.
The canonical authoring form for process manifest version fields is a release-version string in MAJOR.MINOR.PATCH form such as 2.3.0.
For compatibility, the catalog, workflow, and exec-workflow schemas MAY still accept a positive integer version in the v1 line.
\nWhen both forms are technically accepted:
\nImplementations MUST support JSON Schema Draft 2020-12.
\nWhen section visibility or required content depends on prior answers, implementations MUST enforce those dependencies with JSON Schema mechanisms such as if/then/else, dependentRequired, or dependentSchemas rather than treating them as optional reviewer interpretation.
Within this Document Role, the following format-bearing constraints MUST be treated as assertions by a conforming validator:
\ndatedate-timeuriuri-referenceValidators MUST NOT silently downgrade those checks to annotation-only behavior for conformance decisions.
\nA conforming validator or publisher MUST resolve catalog-root-relative paths with the following algorithm:
\ncatalog.manifest.json as the catalog root,/,\\,C:,/,. segment, or .. segment,/ for logical resolution,The path language of v1.0.0 is intentionally the ASCII-like language enforced by the published path regexes. This release does not define additional Unicode normalization behavior.
\nWithin Cuddler core, adjunct, and publication instance documents, $schema is an application-level schema locator that identifies the canonical validation schema for the instance document.
Within support manifests and registries such as specification.index.json, semantic-rules.json, conformance.manifest.json, tests/manifest.json, implementation-record.template.json, and examples.manifest.json, $schema identifies the Cuddler-published instance schema for that support artifact type.
A conforming validator MUST resolve schemas as follows:
\n$schema string from the instance document,specification.index.json,AUT-SCHEMA-001,specification.index.json,AUT-SCHEMA-002.For public Cuddler release validation, offline pinned release-local schemas are RECOMMENDED over live network fetches.
\nValidators MUST NOT prefer an arbitrary same-filename local file over the canonical schema-identifier mapping when the two disagree.
\nSchema validation checks one document at a time.
\nSemantic validation checks cross-file relationships and release-specific invariants that cannot be expressed adequately in one schema alone.
\nThe machine-readable semantic rule registry for this release is semantic-rules.json.
At minimum, a conforming validator MUST implement these public rule identifiers:
\nAUT-SCHEMA-001: schema could not be resolvedAUT-SCHEMA-002: resolved schema bytes did not match the pinned release schema digestAUT-SCHEMA-003: JSON Schema validation failedAUT-SEM-001: each catalog.manifest.json.workflows[].id MUST equal the id inside the referenced workflow.manifest.jsonAUT-SEM-002: each declared workflow path MUST resolve to an existing workflow.manifest.json within the catalog rootAUT-SEM-003: each workflow step id MUST be unique within its owning workflowAUT-SEM-004: each declared questionnairePath MUST resolve to an existing *.process.jsonAUT-SEM-005: each declared scriptPath MUST resolve to an existing script assetAUT-SEM-006: each *.process.json.questionnaireId MUST match the owning step idAUT-SEM-007: each referenced adjunct manifest path MUST resolve to the declared adjunct artifact typeAUT-SEM-008: duplicated feed-item summary fields MUST equal their embedded manifest counterparts when both are presentAUT-SEM-009: duplicate workflow reference ids within a catalog MUST be rejectedAUT-SEM-010: duplicate publication package identity tuples (catalogId, version) within one feed MUST be rejectedAUT-SEM-011: each *.process.json.entryQuestionId MUST resolve to one declared question id in the same questionnaire documentAUT-SEM-012: each declared questionId in one *.process.json document MUST be unique within that questionnaire documentAUT-SEM-013: each routing nextQuestionId in one *.process.json document MUST resolve to an existing question id in the same questionnaire document unless the route marks completionA conforming validator MUST emit a JSON object matching diagnostics.schema.json.
Each diagnostic entry MUST include:
\nmessageseverityartifactPathruleIdWhen available, a diagnostic SHOULD also include:
\ncodeinstancePathschemaPathexpectedactualrelatedArtifactPathinstancePath MUST be an RFC 6901 JSON Pointer.
schemaPath MUST be an RFC 6901 JSON Pointer into the resolved schema document.
Errors fail conformance. Warnings and info entries do not.
\nThe following equality rules are normative:
\nquestionnaireId MUST equal the owning step id,catalog.workflows[].id MUST equal the referenced workflow id,feedItem summary fields are present for displayName, description, author, organization, categories, or tags, they MUST equal the corresponding fields inside manifest.The following fields are intentionally allowed to differ:
\nworkflow.steps[].title and *.process.json.title,workflow.steps[].summary and *.process.json.summary.Schema failure example:
\n{\n "specVersion": "1.0.0",\n "valid": false,\n "diagnostics": [\n {\n "message": "Required property \\"workflows\\" is missing.",\n "severity": "error",\n "artifactPath": "catalogs/customer-success-playbooks/catalog.manifest.json",\n "instancePath": "",\n "schemaPath": "/required",\n "ruleId": "AUT-SCHEMA-003",\n "expected": [\n "$schema",\n "id",\n "version",\n "name",\n "description",\n "workflows"\n ]\n }\n ]\n}\nSemantic failure example:
\n{\n "specVersion": "1.0.0",\n "valid": false,\n "diagnostics": [\n {\n "message": "workflow reference id \\"lead-intake\\" does not match the referenced workflow id \\"lead-intake-v2\\".",\n "severity": "error",\n "artifactPath": "catalogs/customer-success-playbooks/catalog.manifest.json",\n "instancePath": "/workflows/0/id",\n "ruleId": "AUT-SEM-001",\n "relatedArtifactPath": "catalogs/customer-success-playbooks/lead-intake/workflow.manifest.json",\n "expected": "lead-intake-v2",\n "actual": "lead-intake"\n }\n ]\n}\nfeed.json is the publication profile for published process packages.
It is derived output. It MUST NOT be treated as independently authored truth for the source contract.
\nWhen a conforming publisher derives one feedItem from one valid source catalog and no separate publication profile supplies overriding metadata:
catalogId and manifest.catalogId MUST be derived from catalog.manifest.json.id,version and manifest.version MUST be derived from the published package version,manifest.contractVersion MUST be set to 1.0.0,manifest.displayName MUST be derived from catalog.manifest.json.name,manifest.description MUST be derived from catalog.manifest.json.description,displayName and root description, when present, MUST equal the manifest values,manifest.workflows[] MUST be emitted in the same order as the source catalog workflow references,manifest.workflows[].workflowId MUST be derived from the referenced workflow manifest id,manifest.workflows[].title MUST be derived from the referenced workflow manifest name,manifest.workflows[].relativePath MUST default to the catalog workflow reference path,manifest.supportAssets[] MUST be derived from every declared scriptPath in workflow order, then step order,assetId MUST be <workflow-id>-<step-id>-script,relativePath MUST default to the source scriptPath,description MUST be Supporting script for step \"<step title>\" in workflow \"<workflow name>\".,packageSha256 MUST be computed over the exact bytes of the published zip artifact,publishedOnUtc at both the root and manifest levels MUST be UTC timestamps with a trailing Z.The following feed fields are publication-only metadata and are OPTIONAL in v1.0.0 unless a separate publication profile or publisher policy supplies them:
\nauthororganizationcategoriestagsinstallationSummaryWhen duplicated at both the root feed-item level and the embedded manifest level, they MUST remain equal.
\nA conforming publisher MUST:
\n(catalogId, version) tuples within one generated feed,catalogId, then by Semantic Version precedence of version,For v1.0.0, downloadUrl remains the historical field name even though the value is package-relative rather than an absolute URL.
Artifact authoring profiles in this domain MUST be definitive. If a language, status value, date rule, section count, branch type, approval stage, or evidence requirement can be fixed by the standard, it MUST be fixed directly in schema constraints rather than inferred from example documents.
\nExample documents MAY inform only business-domain vocabulary, actor labels, decision criteria, and operational content that the governing specifications cannot already determine.
\ncatalog.manifest.jsonA conforming source catalog.manifest.json MUST define:
$schemaidversionnamedescriptionworkflowsIt MAY define:
\nsourceRepositoryexportedAtsourcePluginpluginManifestPathskillManifestPathworkflowBundlePathworkflow.manifest.jsonA conforming source workflow.manifest.json MUST define:
$schemaidversionnamedescriptionstepsWorkflow steps[] MUST preserve execution order exactly as authored.
When a workflow can branch or conditionally require later sections, the schema MUST define the gating fields, allowed branch types, and inclusion or exclusion rules explicitly so validators can determine which sections are valid without human guesswork.
\nEach step MUST define:
\nidtitlequestionnairePathEach step MAY define:
\nsummaryscriptPathIn v1.0.0, scriptPath remains a PowerShell-shaped adjunct path ending in script.ps1. That is an explicit v1 scope constraint, not a claim of cross-runtime execution neutrality for script assets.
*.process.jsonA conforming *.process.json document MUST define:
$schemaquestionnaireIdtitleentryQuestionIdquestionsIt MAY define:
\nsummaryinstructionsformatWhen a workflow step uses one *.process.json document as its source artifact, the document is a question-driven step contract rather than a free-form questionnaire note.
Each question MUST define:
\nquestionIdtitleanswerTypeoutputKeyconversation as a JSON array containing one or more JSONL-style record objects with messages[]routingfor-aiQuestions with answer types select-one or select-many MUST also define explicit options[].
instructions remains an optional Markdown field for step-level operating notes, but question-specific capture rules, answer typing, output evaluation, and next-question selection belong in the typed question objects.
Each completed user conversation is the evidence the AI uses to derive the question output by following the question's for-ai guidance and routing rules.
In v1.0.0, omitted format values are treated as markdown. The field remains in the schema for explicitness and machine-readability when instructions is present.
plugin.manifest.json, skill.manifest.json, and exec.workflow.json remain optional companion adjunct profiles in v1.0.0.
They MUST NOT replace the source authority of:
\ncatalog.manifest.jsonworkflow.manifest.json*.process.jsonThis section is normative.
\nImplementations and authors MUST account for at least the following risks:
\nConforming validators and publishers MUST:
\npackageSha256 as an integrity field over exact artifact bytes,This section is normative.
\nThe core contract defined here does not itself authorize access to private data sources.
\nImplementations MUST assume that questionnaire content, summaries, publication descriptions, provenance fields, and example datasets may contain sensitive information.
\nImplementations SHOULD:
\nThis Document Role family recognizes the following status states:
\ndraftstabledeprecatedobsoletev1.0.0 is stable.
Non-breaking clarifications and hardening changes MAY be released as patch versions.
\nPatch releases MUST preserve:
\n$id values for the v1 line,Breaking changes MUST use a new major version.
\nExamples include:
\nfeed.json array shape,catalog.workflows[].id or questionnaireId.For this public Document Role family:
\nThe machine-readable example bundle for this release is published as examples.manifest.json.
The examples intentionally use source/package version 2.3.0 and feed contractVersion 1.0.0 so readers can distinguish artifact/package versioning from Document Role versioning.
The conformance test bundle for this release is published under tests/ with a machine-readable index at tests/manifest.json.
Every public rule identifier in Section 12.2 is exercised by at least one published fixture.
\nThe v1.0.0 public surface is intentionally sufficient for:
\nThe following execution-oriented surfaces remain intentionally out of scope for v1.0.0 and are candidates for a future additive release:
\nfor-ai arrays on schema nodes. Consumers of Cuddler standards should parse and follow that guidance when preparing Data, Template, and Process values, and each Alpaca-format entry should carry instruction, input, and output fields.",
"Prefer definitive Process schema constraints whenever a rule is knowable: fix language, meta.status, date or date-time handling, identifier formats, path rules, exact workflow or step counts, file-shape limits, and section cardinality in schema logic instead of leaving them open to examples.",
"For workflow steps backed by questionnaires, define typed questions with explicit answer types from select-one, select-many, number, short-text, long-text, date, and percentage, store conversation as a JSON array of JSONL-style record objects, publish question-level for-ai evaluation guidance, and make next-question and next-step routing deterministic so consumers can collect completed conversations and derive normalized question outputs.",
"When one answer determines whether another section appears, encode that dependency with explicit discriminator fields and JSON Schema conditionals such as if/then/else, dependentRequired, or dependentSchemas instead of relying on narrative instructions.",
"Do not infer optionality, alternate branch sets, or broader workflow shapes from missing or conflicting examples; keep those conflicts in a brief unresolved-assumptions note outside the schema.",
"Ensure every Artifact Definition classified into this domain also conforms to the shared Artifact Specification and identifies both governing documents explicitly.",
"Preserve the catalog-to-workflow-to-step model while supporting complex standard operating procedures or business processes through typed branching, approvals, exceptions, roles, and evidence structures, and treat real operational Artifact Documents as confidential by default unless a public example is intentionally published."
],
"validationWorkflow": [
"Resolve the declared schema, run JSON Schema validation, then run deterministic semantic validation for cross-file and publication rules, then emit diagnostics.",
"Fail authoring-profile validation when a required schema-node for-ai array is missing, malformed, or empty where the governing standards require one.",
"Fail when *.process.json question ids, entryQuestionId, answer-type-specific option requirements, question-level for-ai evaluation guidance, or routing targets drift from the v1.0.0 contract.",
"Fail when identifiers, prompts, workflow references, conditional section gates, package metadata, feed derivation, or publication bundle rules drift from the v1.0.0 contract.",
"Use the published diagnostics schema, semantic rules, conformance manifest, and test fixtures to keep validator and publisher behavior stable, and treat user-provided examples as supporting business-domain structure rather than replacement rules."
],
"publicationNotes": [
"Publish the canonical self-contained normative document as document-role-specification.json beside the supporting schemas, manifests, examples, and tests.",
"Publish AI-facing schema-node guidance in for-ai Alpaca arrays instead of relying on JSON Schema description as the instruction channel.",
"For workflow publications that include questionnaire-backed steps, publish typed questionnaires whose question nodes carry answer types, conversation stored as a JSON array of JSONL-style record objects, question-level for-ai guidance, and routing rules.",
"State the exact canonical schema-file inventory and what each published file validates whenever a Process Artifact Definition bundle contains multiple machine-readable files.",
"Do not publish separate Markdown or HTML prose documents for this process Document Role family.",
"Preserve attribution and include the original public URL when this Document Role, the Artifact Specification, or domain-classified Artifact Definitions are reused or adapted."
]
},
"artifactGroups": [
{
"key": "normative-artifacts",
"title": "Normative Artifacts",
"items": [
{
"id": "document-role-specification-document",
"title": "Document Role document",
"role": "document-role-specification",
"publicationClass": "normative",
"mediaType": "application/json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/document-role-specification.json"
},
{
"id": "catalog-schema",
"title": "Catalog manifest schema",
"role": "catalog-schema",
"publicationClass": "normative",
"mediaType": "application/schema+json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/catalog.manifest.schema.json"
},
{
"id": "workflow-schema",
"title": "Workflow manifest schema",
"role": "workflow-schema",
"publicationClass": "normative",
"mediaType": "application/schema+json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/workflow.manifest.schema.json"
},
{
"id": "questionnaire-schema",
"title": "Questionnaire schema",
"role": "questionnaire-schema",
"publicationClass": "normative",
"mediaType": "application/schema+json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/questionnaire.schema.json"
},
{
"id": "feed-schema",
"title": "Feed schema",
"role": "feed-schema",
"publicationClass": "normative",
"mediaType": "application/schema+json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/feed.schema.json"
},
{
"id": "plugin-manifest-schema",
"title": "Plugin manifest schema",
"role": "plugin-schema",
"publicationClass": "normative",
"mediaType": "application/schema+json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/plugin.manifest.schema.json"
},
{
"id": "skill-manifest-schema",
"title": "Skill manifest schema",
"role": "skill-schema",
"publicationClass": "normative",
"mediaType": "application/schema+json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/skill.manifest.schema.json"
},
{
"id": "exec-workflow-schema",
"title": "Executable workflow schema",
"role": "exec-workflow-schema",
"publicationClass": "normative",
"mediaType": "application/schema+json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/exec.workflow.schema.json"
}
]
},
{
"key": "supporting-artifacts",
"title": "Supporting Artifacts",
"items": [
{
"id": "diagnostics-schema",
"title": "Diagnostics schema",
"role": "diagnostics-schema",
"publicationClass": "supporting",
"mediaType": "application/schema+json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/diagnostics.schema.json"
},
{
"id": "semantic-rules",
"title": "Semantic rules",
"role": "semantic-rules",
"publicationClass": "supporting",
"mediaType": "application/json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/semantic-rules.json"
},
{
"id": "semantic-rules-schema",
"title": "Semantic rules schema",
"role": "semantic-rules-schema",
"publicationClass": "supporting",
"mediaType": "application/schema+json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/semantic-rules.schema.json"
},
{
"id": "artifact-index",
"title": "Artifact index",
"role": "artifact-index",
"publicationClass": "supporting",
"mediaType": "application/json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/specification.index.json"
},
{
"id": "artifact-index-schema",
"title": "Artifact index schema",
"role": "artifact-index-schema",
"publicationClass": "supporting",
"mediaType": "application/schema+json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/specification.index.schema.json"
},
{
"id": "conformance-manifest",
"title": "Conformance manifest",
"role": "conformance-manifest",
"publicationClass": "supporting",
"mediaType": "application/json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/conformance.manifest.json"
},
{
"id": "conformance-manifest-schema",
"title": "Conformance manifest schema",
"role": "conformance-manifest-schema",
"publicationClass": "supporting",
"mediaType": "application/schema+json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/conformance.manifest.schema.json"
},
{
"id": "tests-manifest",
"title": "Conformance tests manifest",
"role": "tests-manifest",
"publicationClass": "supporting",
"mediaType": "application/json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/tests/manifest.json"
},
{
"id": "tests-manifest-schema",
"title": "Conformance tests manifest schema",
"role": "tests-manifest-schema",
"publicationClass": "supporting",
"mediaType": "application/schema+json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/tests.manifest.schema.json"
},
{
"id": "implementation-template",
"title": "Implementation record template",
"role": "implementation-template",
"publicationClass": "supporting",
"mediaType": "application/json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/implementation-record.template.json"
},
{
"id": "implementation-record-schema",
"title": "Implementation record schema",
"role": "implementation-record-schema",
"publicationClass": "supporting",
"mediaType": "application/schema+json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/implementation-record.schema.json"
},
{
"id": "examples-manifest",
"title": "Examples manifest",
"role": "examples-manifest",
"publicationClass": "supporting",
"mediaType": "application/json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/examples.manifest.json"
},
{
"id": "examples-manifest-schema",
"title": "Examples manifest schema",
"role": "examples-manifest-schema",
"publicationClass": "supporting",
"mediaType": "application/schema+json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/examples.manifest.schema.json"
}
]
},
{
"key": "example-artifacts",
"title": "Example Artifacts",
"items": [
{
"id": "feed-example",
"title": "Feed example",
"role": "example",
"publicationClass": "example",
"mediaType": "application/json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/examples/feed.example.json"
},
{
"id": "catalog-example",
"title": "Customer success catalog example",
"role": "example",
"publicationClass": "example",
"mediaType": "application/json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/examples/customer-success-playbooks/catalog.manifest.json"
},
{
"id": "workflow-example",
"title": "Lead intake workflow example",
"role": "example",
"publicationClass": "example",
"mediaType": "application/json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/examples/customer-success-playbooks/lead-intake/workflow.manifest.json"
},
{
"id": "capture-context-questionnaire-example",
"title": "Capture context questionnaire example",
"role": "example",
"publicationClass": "example",
"mediaType": "application/json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/examples/customer-success-playbooks/lead-intake/capture-context.process.json"
},
{
"id": "draft-follow-up-questionnaire-example",
"title": "Draft follow-up questionnaire example",
"role": "example",
"publicationClass": "example",
"mediaType": "application/json",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/examples/customer-success-playbooks/lead-intake/draft-follow-up.process.json"
},
{
"id": "draft-follow-up-script-example",
"title": "Draft follow-up script example",
"role": "example",
"publicationClass": "example",
"mediaType": "text/plain",
"url": "https://www.cuddler.dev/standards/document-role/process/v1.0.0/examples/customer-success-playbooks/lead-intake/draft-follow-up/script.ps1"
}
]
}
],
"sectionSummaries": [
{
"key": "overview",
"title": "Overview",
"summary": "Defines the Process-governed authoring brief as a single self-contained normative publication for catalog-workflow-step structure, conditional section rules, validation, and publication-ready process artifacts."
},
{
"key": "scope",
"title": "Scope",
"summary": "Explains the process source model, identifier and path rules, publication artifacts, diagnostics, conformance classes, non-goals, and fixed schema constraints a Process Artifact Definition must cover, including explicit metadata values, conditional section gates, branching workflow structures, and exact cardinality rules when knowable."
},
{
"key": "implementation",
"title": "Implementation",
"summary": "Tells schema authors, validators, and publishers how to interpret core artifacts, adjunct profiles, deterministic section-inclusion logic, and feed derivation rules when drafting or enforcing the family with strict schema rules and without widening the contract to absorb example drift."
},
{
"key": "validation",
"title": "Validation",
"summary": "Requires schema resolution and validation first, deterministic semantic and conditional-gating checks second, and stable rule identifiers for cross-file failures."
},
{
"key": "artifacts",
"title": "Artifacts",
"summary": "Identifies the supporting manifests, examples, tests, and registries that can guide drafting without replacing the normative contract inside the Document Role document."
},
{
"key": "security",
"title": "Security",
"summary": "Includes the normative security and privacy expectations needed to author and publish process packages safely without hidden assumptions."
},
{
"key": "change-management",
"title": "Change Management",
"summary": "Captures versioning, patch-release constraints, breaking-change boundaries, and reuse expectations inside the canonical versioned document."
},
{
"key": "references",
"title": "References",
"summary": "Provides the RFC and JSON Schema references needed to interpret identifiers, paths, pointers, media types, and publication rules."
}
],
"references": {
"normative": [
{
"title": "BCP 14 / RFC 2119 / RFC 8174",
"locator": "Requirement language"
},
{
"title": "RFC 3986",
"locator": "URI Generic Syntax"
},
{
"title": "RFC 6570",
"locator": "URI Template"
},
{
"title": "RFC 6901",
"locator": "JSON Pointer"
},
{
"title": "RFC 7763",
"locator": "text/markdown media type"
},
{
"title": "JSON Schema Draft 2020-12 Core",
"locator": "Core vocabulary"
},
{
"title": "JSON Schema Draft 2020-12 Validation",
"locator": "Validation vocabulary"
},
{
"title": "JSON Schema Draft 2020-12 Recommended Output",
"locator": "Recommended output vocabulary"
}
],
"informative": [
{
"title": "Template Document Role v1.0.0",
"locator": "https://www.cuddler.dev/standards/document-role/template/"
},
{
"title": "Data Document Role v1.0.0",
"locator": "https://www.cuddler.dev/standards/document-role/data/"
}
]
}
}
}