Templates
Author a template
Consultants author templates as members of the authoring workspace, using the ruleset editor. Template authoring does not grant access to customer ruleset content, rationales or runs. Authors can inspect assignment and adoption metadata.
Every ruleset save requires a rationale, including a from-scratch ruleset. Give a new reason or explicitly reuse the previous rationale within the working version. Reuse is recorded as a link; typing identical text again is refused. Rationales accompany the affected step occurrences in comparisons. Steps with the same visible identifier in different branch arms remain distinct.
Publish a version
An approver in the authoring workspace publishes a working version after its publication gate passes. The gate runs all fixtures and requires complete German and English template metadata and declared messages. It records the exact revision, document and fixture-content hashes, results and engine identity. Publication refuses stale results or fixture content changed after the gate. The passing record becomes part of the immutable published version.
Template versions use integers. The contract-impact indicator compares the declared input and output schemas and document inputs with the previous version; it is not a promise about every business behavior. The e-invoice coverage page states that template's proved subset and exclusions, with independent external agreement still pending.
A faulty publication is deprecated with a reason, rather than edited or deleted. Deprecation removes it from new offers and leaves its reason visible to tenants holding a copy. Publish a new version for the correction.
Assign and adopt
Assignment gives a tenant access to that template's available published versions. Adoption creates a full tenant-owned copy of the ruleset and its fixtures, including fixture document assets and recordings, with the base template version recorded. Changes to the tenant copy require rationales. The authoring template and the customer's copy have separate content.
The adoption screen lists dataset and model-alias dependencies. Missing dependencies are warnings while adopting; activation checks whether the required dependencies can be bound.
Move to a newer version
Assigned tenants see newer-version offers and a comparison before choosing an upgrade. Starting from a newer template creates a new working version of the same tenant ruleset and advances its base template reference. The active tenant version remains in use until activation changes it.
Use the mechanical comparison and the captured rationales to reapply customer modifications by hand. The comparison shows added, removed, changed and moved step occurrences, field changes, contract groups and raw JSON. The product decision for this version is mechanical comparison with manual reapplication; automatic three-way merging is outside this version's scope.