ssot-contracts 0.2.17.dev1__tar.gz → 0.2.18.dev1__tar.gz

{ssot_contracts-0.2.17.dev1 → ssot_contracts-0.2.18.dev1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: ssot-contracts
-Version: 0.2.17.dev1
+Version: 0.2.18.dev1
 Summary: Canonical schemas, templates, manifests, and generated Python contract artifacts for SSOT.
 Author-email: Jacob Stewart <jacob@swarmauri.com>
 License-Expression: Apache-2.0
@@ -19,13 +19,14 @@ Classifier: Programming Language :: Python :: 3.10
 Classifier: Programming Language :: Python :: 3.11
 Classifier: Programming Language :: Python :: 3.12
 Classifier: Programming Language :: Python :: 3.13
+Classifier: Programming Language :: Python :: 3.14
 Classifier: Topic :: File Formats :: JSON
 Classifier: Topic :: File Formats :: JSON :: JSON Schema
 Classifier: Topic :: Software Development :: Documentation
 Classifier: Topic :: Software Development :: Libraries :: Python Modules
 Classifier: Topic :: Software Development :: Quality Assurance
 Classifier: Topic :: Utilities
-Requires-Python: <3.14,>=3.10
+Requires-Python: <3.15,>=3.10
 Description-Content-Type: text/markdown
 Requires-Dist: tomli>=2.0.1; python_version < "3.11"
 
@@ -39,6 +40,10 @@ Requires-Dist: tomli>=2.0.1; python_version < "3.11"
   <a href="https://pypi.org/project/ssot-contracts/"><img src="https://img.shields.io/pypi/pyversions/ssot-contracts?label=Python" alt="Supported Python versions" /></a>
   <a href="https://pepy.tech/project/ssot-contracts"><img src="https://static.pepy.tech/badge/ssot-contracts" alt="Downloads" /></a>
   <a href="https://hits.sh/github.com/groupsum/ssot-registry/"><img src="https://hits.sh/github.com/groupsum/ssot-registry.svg?style=flat-square" alt="Repository hits" /></a>
+<!-- ssot-schema-badges:start -->
+  <img src="https://img.shields.io/badge/schema_version-0.5.0-blue" alt="schema_version 0.5.0" />
+  <img src="https://img.shields.io/badge/migration%20coverage-12%2F12-brightgreen" alt="Migration coverage 12/12" />
+<!-- ssot-schema-badges:end -->
 </div>
 
 `ssot-contracts` is the canonical artifact package for SSOT.

{ssot_contracts-0.2.17.dev1 → ssot_contracts-0.2.18.dev1}/README.md

@@ -8,6 +8,10 @@
   <a href="https://pypi.org/project/ssot-contracts/"><img src="https://img.shields.io/pypi/pyversions/ssot-contracts?label=Python" alt="Supported Python versions" /></a>
   <a href="https://pepy.tech/project/ssot-contracts"><img src="https://static.pepy.tech/badge/ssot-contracts" alt="Downloads" /></a>
   <a href="https://hits.sh/github.com/groupsum/ssot-registry/"><img src="https://hits.sh/github.com/groupsum/ssot-registry.svg?style=flat-square" alt="Repository hits" /></a>
+<!-- ssot-schema-badges:start -->
+  <img src="https://img.shields.io/badge/schema_version-0.5.0-blue" alt="schema_version 0.5.0" />
+  <img src="https://img.shields.io/badge/migration%20coverage-12%2F12-brightgreen" alt="Migration coverage 12/12" />
+<!-- ssot-schema-badges:end -->
 </div>
 
 `ssot-contracts` is the canonical artifact package for SSOT.

{ssot_contracts-0.2.17.dev1 → ssot_contracts-0.2.18.dev1}/pyproject.toml

@@ -4,10 +4,10 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "ssot-contracts"
-version = "0.2.17.dev1"
+version = "0.2.18.dev1"
 description = "Canonical schemas, templates, manifests, and generated Python contract artifacts for SSOT."
 readme = "README.md"
-requires-python = ">=3.10,<3.14"
+requires-python = ">=3.10,<3.15"
 license = "Apache-2.0"
 authors = [{ name = "Jacob Stewart", email = "jacob@swarmauri.com" }]
 dependencies = ["tomli>=2.0.1; python_version < '3.11'"]
@@ -24,6 +24,7 @@ classifiers = [
   "Programming Language :: Python :: 3.11",
   "Programming Language :: Python :: 3.12",
   "Programming Language :: Python :: 3.13",
+  "Programming Language :: Python :: 3.14",
   "Topic :: File Formats :: JSON",
   "Topic :: File Formats :: JSON :: JSON Schema",
   "Topic :: Software Development :: Documentation",

{ssot_contracts-0.2.17.dev1 → ssot_contracts-0.2.18.dev1}/src/ssot_contracts/contract_data.py

@@ -1,7 +1,7 @@
 from __future__ import annotations
 
 CONTRACT_DATA = {
-    "schema_version": "0.4.0",
+    "schema_version": "0.6.0",
     "output_formats": ["json", "csv", "df", "yaml", "toml"],
     "entity_sections": [
         {"key": "features", "label": "Features"},
@@ -72,6 +72,7 @@ CONTRACT_DATA = {
         "severities": ["low", "medium", "high", "critical"],
         "document_statuses": ["draft", "in_review", "accepted", "rejected", "superseded", "withdrawn", "retired"],
         "spec_kinds": ["normative", "operational", "governance", "local-policy"],
+        "assurance_origins": ["ssot-core", "ssot-origin", "extension-pack", "repo-local"],
     },
     "document_contract": {
         "kinds": ["adr", "spec"],

{ssot_contracts-0.2.17.dev1 → ssot_contracts-0.2.18.dev1}/src/ssot_contracts/generated/python/enums.py

@@ -23,3 +23,4 @@ RELEASE_STATUSES = set(CONTRACT_DATA["choice_sets"]["release_statuses"])
 SEVERITIES = set(CONTRACT_DATA["choice_sets"]["severities"])
 DOCUMENT_STATUSES = tuple(CONTRACT_DATA["choice_sets"]["document_statuses"])
 SPEC_KINDS = set(CONTRACT_DATA["choice_sets"]["spec_kinds"])
+ASSURANCE_ORIGINS = set(CONTRACT_DATA["choice_sets"]["assurance_origins"])

ssot_contracts-0.2.18.dev1/src/ssot_contracts/schema/registry.schema.json

@@ -0,0 +1 @@
+{"$defs":{"adr":{"additionalProperties":true,"properties":{"content_sha256":{"pattern":"^[a-f0-9]{64}$","type":"string"},"id":{"$ref":"#/$defs/normalizedId"},"immutable":{"type":"boolean"},"managed":{"type":"boolean"},"number":{"minimum":1,"type":"integer"},"origin":{"enum":["ssot-core","ssot-origin","extension-pack","repo-local"]},"package_version":{"minLength":1,"type":"string"},"path":{"minLength":1,"type":"string"},"slug":{"pattern":"^[a-z0-9]+(?:-[a-z0-9]+)*$","type":"string"},"source_document_id":{"$ref":"#/$defs/normalizedId"},"source_document_kind":{"enum":["adr","spec"]},"source_pack_id":{"$ref":"#/$defs/normalizedId"},"source_package_name":{"minLength":1,"type":"string"},"status":{"$ref":"#/$defs/documentStatus"},"status_notes":{"items":{"$ref":"#/$defs/statusNote"},"type":"array"},"superseded_by":{"$ref":"#/$defs/stringList"},"supersedes":{"$ref":"#/$defs/stringList"},"title":{"minLength":1,"type":"string"}},"required":["id","number","slug","title","path","origin","managed","immutable","package_version","content_sha256","status","supersedes","superseded_by","status_notes"],"type":"object"},"assuranceOrigin":{"enum":["ssot-core","ssot-origin","extension-pack","repo-local"]},"boundary":{"additionalProperties":true,"properties":{"body":{"type":"string"},"feature_ids":{"$ref":"#/$defs/stringList"},"frozen":{"type":"boolean"},"id":{"$ref":"#/$defs/normalizedId"},"profile_ids":{"items":{"type":"string"},"type":"array"},"status":{"enum":["draft","active","frozen","retired"]},"title":{"minLength":1,"type":"string"}},"required":["id","title","status","frozen","feature_ids","profile_ids"],"type":"object"},"claim":{"additionalProperties":true,"properties":{"body":{"type":"string"},"depends_on_claim_ids":{"$ref":"#/$defs/stringList"},"description":{"type":"string"},"evidence_ids":{"$ref":"#/$defs/stringList"},"feature_ids":{"$ref":"#/$defs/stringList"},"id":{"$ref":"#/$defs/normalizedId"},"kind":{"minLength":1,"type":"string"},"origin":{"$ref":"#/$defs/assuranceOrigin"},"status":{"enum":["proposed","declared","implemented","asserted","evidenced","certified","promoted","published","blocked","retired"]},"test_ids":{"$ref":"#/$defs/stringList"},"tier":{"enum":["T0","T1","T2","T3","T4"]},"title":{"minLength":1,"type":"string"}},"required":["id","title","status","tier","kind","description","feature_ids","test_ids","evidence_ids","origin","depends_on_claim_ids"],"type":"object"},"documentIdReservations":{"additionalProperties":false,"properties":{"adr":{"items":{"$ref":"#/$defs/documentReservationRange"},"type":"array"},"spec":{"items":{"$ref":"#/$defs/documentReservationRange"},"type":"array"}},"required":["adr","spec"],"type":"object"},"documentReservationRange":{"additionalProperties":true,"properties":{"assignable_by_repo":{"type":"boolean"},"deletable":{"type":"boolean"},"end":{"minimum":1,"type":"integer"},"immutable":{"type":"boolean"},"owner":{"minLength":1,"type":"string"},"start":{"minimum":1,"type":"integer"}},"required":["owner","start","end","immutable","deletable","assignable_by_repo"],"type":"object"},"documentStatus":{"enum":["draft","in_review","accepted","rejected","superseded","withdrawn","retired"]},"evidence":{"additionalProperties":true,"properties":{"body":{"type":"string"},"claim_ids":{"$ref":"#/$defs/stringList"},"id":{"$ref":"#/$defs/normalizedId"},"kind":{"minLength":1,"type":"string"},"origin":{"$ref":"#/$defs/assuranceOrigin"},"path":{"minLength":1,"type":"string"},"status":{"enum":["planned","collected","passed","failed","stale"]},"test_ids":{"$ref":"#/$defs/stringList"},"tier":{"enum":["T0","T1","T2","T3","T4"]},"title":{"minLength":1,"type":"string"}},"required":["id","title","status","kind","tier","path","claim_ids","test_ids","origin"],"type":"object"},"feature":{"additionalProperties":true,"properties":{"body":{"type":"string"},"claim_ids":{"$ref":"#/$defs/stringList"},"description":{"type":"string"},"id":{"$ref":"#/$defs/normalizedId"},"implementation_status":{"enum":["absent","partial","implemented"]},"lifecycle":{"$ref":"#/$defs/featureLifecycle"},"origin":{"$ref":"#/$defs/assuranceOrigin"},"plan":{"$ref":"#/$defs/featurePlan"},"requires":{"$ref":"#/$defs/stringList"},"spec_ids":{"$ref":"#/$defs/stringList"},"test_ids":{"$ref":"#/$defs/stringList"},"title":{"minLength":1,"type":"string"}},"required":["id","title","description","implementation_status","lifecycle","plan","spec_ids","claim_ids","test_ids","origin"],"type":"object"},"featureLifecycle":{"additionalProperties":true,"properties":{"effective_release_id":{"type":["string","null"]},"note":{"type":["string","null"]},"replacement_feature_ids":{"$ref":"#/$defs/stringList"},"stage":{"enum":["active","deprecated","obsolete","removed"]}},"required":["stage","replacement_feature_ids","note"],"type":"object"},"featurePlan":{"additionalProperties":true,"properties":{"horizon":{"enum":["current","next","future","explicit","backlog","out_of_bounds"]},"out_of_bounds_disposition":{"enum":["prohibited","tolerated",null],"type":["string","null"]},"slot":{"type":["string","null"]},"target_claim_tier":{"enum":["T0","T1","T2","T3","T4",null],"type":["string","null"]},"target_lifecycle_stage":{"enum":["active","deprecated","obsolete","removed"]}},"required":["horizon","slot","target_claim_tier","target_lifecycle_stage"],"type":"object"},"guardPolicies":{"additionalProperties":true,"type":"object"},"issue":{"additionalProperties":true,"properties":{"body":{"type":"string"},"claim_ids":{"$ref":"#/$defs/stringList"},"description":{"type":"string"},"evidence_ids":{"$ref":"#/$defs/stringList"},"feature_ids":{"$ref":"#/$defs/stringList"},"id":{"$ref":"#/$defs/normalizedId"},"plan":{"$ref":"#/$defs/issuePlan"},"release_blocking":{"type":"boolean"},"risk_ids":{"$ref":"#/$defs/stringList"},"severity":{"enum":["low","medium","high","critical"]},"status":{"enum":["open","in_progress","blocked","resolved","closed"]},"test_ids":{"$ref":"#/$defs/stringList"},"title":{"minLength":1,"type":"string"}},"required":["id","title","status","severity","description","plan","feature_ids","claim_ids","test_ids","evidence_ids","risk_ids","release_blocking"],"type":"object"},"issuePlan":{"additionalProperties":true,"properties":{"horizon":{"enum":["current","next","future","explicit","backlog","out_of_bounds"]},"slot":{"type":["string","null"]}},"required":["horizon","slot"],"type":"object"},"normalizedId":{"maxLength":128,"pattern":"^[a-z][a-z0-9-]*:[a-z0-9][a-z0-9._-]*$","type":"string"},"paths":{"additionalProperties":true,"properties":{"adr_root":{"minLength":1,"type":"string"},"cache_root":{"minLength":1,"type":"string"},"evidence_root":{"minLength":1,"type":"string"},"graph_root":{"minLength":1,"type":"string"},"release_root":{"minLength":1,"type":"string"},"report_root":{"minLength":1,"type":"string"},"schema_root":{"minLength":1,"type":"string"},"spec_root":{"minLength":1,"type":"string"},"ssot_root":{"minLength":1,"type":"string"}},"required":["ssot_root","schema_root","adr_root","spec_root","graph_root","evidence_root","release_root","report_root","cache_root"],"type":"object"},"profile":{"additionalProperties":false,"properties":{"body":{"type":"string"},"claim_tier":{"enum":["T0","T1","T2","T3","T4",null],"type":["string","null"]},"description":{"type":"string"},"evaluation":{"additionalProperties":false,"properties":{"allow_feature_override_tier":{"type":"boolean"},"mode":{"enum":["all_features_must_pass"]}},"required":["mode","allow_feature_override_tier"],"type":"object"},"feature_ids":{"$ref":"#/$defs/stringList"},"id":{"$ref":"#/$defs/normalizedId"},"kind":{"enum":["capability","certification","deployment","interoperability"]},"profile_ids":{"$ref":"#/$defs/stringList"},"status":{"enum":["draft","active","retired"]},"title":{"type":"string"}},"required":["id","title","description","status","kind","feature_ids","profile_ids","claim_tier","evaluation"],"type":"object"},"program":{"additionalProperties":true,"properties":{"active_boundary_id":{"$ref":"#/$defs/normalizedId"},"active_release_id":{"$ref":"#/$defs/normalizedId"}},"required":["active_boundary_id","active_release_id"],"type":"object"},"release":{"additionalProperties":true,"properties":{"body":{"type":"string"},"boundary_id":{"$ref":"#/$defs/normalizedId"},"boundary_ids":{"$ref":"#/$defs/stringList"},"claim_ids":{"$ref":"#/$defs/stringList"},"evidence_ids":{"$ref":"#/$defs/stringList"},"id":{"$ref":"#/$defs/normalizedId"},"status":{"enum":["draft","candidate","certified","promoted","published","revoked"]},"version":{"minLength":1,"type":"string"}},"required":["id","version","status","boundary_id","boundary_ids","claim_ids","evidence_ids"],"type":"object"},"repo":{"additionalProperties":true,"properties":{"id":{"$ref":"#/$defs/normalizedId"},"kind":{"enum":["ssot-core","ssot-origin","extension-pack","repo-local"]},"name":{"minLength":1,"type":"string"},"version":{"minLength":1,"type":"string"}},"required":["id","name","version","kind"],"type":"object"},"risk":{"additionalProperties":true,"properties":{"body":{"type":"string"},"claim_ids":{"$ref":"#/$defs/stringList"},"description":{"type":"string"},"evidence_ids":{"$ref":"#/$defs/stringList"},"feature_ids":{"$ref":"#/$defs/stringList"},"id":{"$ref":"#/$defs/normalizedId"},"issue_ids":{"$ref":"#/$defs/stringList"},"release_blocking":{"type":"boolean"},"severity":{"enum":["low","medium","high","critical"]},"status":{"enum":["active","mitigated","accepted","retired"]},"test_ids":{"$ref":"#/$defs/stringList"},"title":{"minLength":1,"type":"string"}},"required":["id","title","status","severity","description","feature_ids","claim_ids","test_ids","evidence_ids","issue_ids","release_blocking"],"type":"object"},"spec":{"additionalProperties":true,"properties":{"adr_ids":{"$ref":"#/$defs/stringList"},"content_sha256":{"pattern":"^[a-f0-9]{64}$","type":"string"},"id":{"$ref":"#/$defs/normalizedId"},"immutable":{"type":"boolean"},"kind":{"enum":["normative","operational","governance","local-policy"]},"managed":{"type":"boolean"},"number":{"minimum":1,"type":"integer"},"origin":{"enum":["ssot-core","ssot-origin","extension-pack","repo-local"]},"package_version":{"minLength":1,"type":"string"},"path":{"minLength":1,"type":"string"},"slug":{"pattern":"^[a-z0-9]+(?:-[a-z0-9]+)*$","type":"string"},"source_document_id":{"$ref":"#/$defs/normalizedId"},"source_document_kind":{"enum":["adr","spec"]},"source_pack_id":{"$ref":"#/$defs/normalizedId"},"source_package_name":{"minLength":1,"type":"string"},"status":{"$ref":"#/$defs/documentStatus"},"status_notes":{"items":{"$ref":"#/$defs/statusNote"},"type":"array"},"superseded_by":{"$ref":"#/$defs/stringList"},"supersedes":{"$ref":"#/$defs/stringList"},"title":{"minLength":1,"type":"string"}},"required":["id","number","slug","title","path","origin","managed","immutable","package_version","content_sha256","kind","adr_ids","status","supersedes","superseded_by","status_notes"],"type":"object"},"statusNote":{"additionalProperties":false,"properties":{"actor":{"minLength":1,"type":"string"},"at":{"minLength":1,"type":"string"},"note":{"minLength":1,"type":"string"},"reason":{"minLength":1,"type":"string"},"status":{"$ref":"#/$defs/documentStatus"}},"required":["status","note","at"],"type":"object"},"stringList":{"items":{"$ref":"#/$defs/normalizedId"},"type":"array"},"test":{"additionalProperties":true,"properties":{"body":{"type":"string"},"claim_ids":{"$ref":"#/$defs/stringList"},"evidence_ids":{"$ref":"#/$defs/stringList"},"execution":{"$ref":"#/$defs/testExecution"},"feature_ids":{"$ref":"#/$defs/stringList"},"id":{"$ref":"#/$defs/normalizedId"},"kind":{"minLength":1,"type":"string"},"origin":{"$ref":"#/$defs/assuranceOrigin"},"path":{"minLength":1,"type":"string"},"status":{"enum":["planned","passing","failing","blocked","skipped"]},"title":{"minLength":1,"type":"string"}},"required":["id","title","status","kind","path","feature_ids","claim_ids","evidence_ids","origin"],"type":"object"},"testExecution":{"additionalProperties":false,"properties":{"argv":{"items":{"type":"string"},"minItems":1,"type":"array"},"cwd":{"minLength":1,"type":"string"},"env":{"additionalProperties":{"type":"string"},"type":"object"},"mode":{"const":"command"},"success":{"$ref":"#/$defs/testExecutionSuccess"},"timeout_seconds":{"exclusiveMinimum":0,"type":"integer"}},"required":["mode","argv","cwd","env","timeout_seconds","success"],"type":"object"},"testExecutionSuccess":{"additionalProperties":false,"properties":{"expected":{"type":"integer"},"type":{"const":"exit_code"}},"required":["type","expected"],"type":"object"},"tooling":{"additionalProperties":true,"properties":{"initialized_with_version":{"minLength":1,"type":"string"},"last_upgraded_from_version":{"minLength":1,"type":"string"},"ssot_registry_version":{"minLength":1,"type":"string"}},"required":["ssot_registry_version","initialized_with_version","last_upgraded_from_version"],"type":"object"}},"$id":"https://example.invalid/ssot-registry/registry.schema.json","$schema":"https://json-schema.org/draft/2020-12/schema","additionalProperties":false,"allOf":[{"if":{"properties":{"repo":{"properties":{"kind":{"const":"repo-local"}},"required":["kind"],"type":"object"}}},"then":{"properties":{"adrs":{"not":{"contains":{"properties":{"origin":{"const":"ssot-core"}},"required":["origin"],"type":"object"}}},"specs":{"not":{"contains":{"properties":{"origin":{"const":"ssot-core"}},"required":["origin"],"type":"object"}}}}}}],"properties":{"adrs":{"items":{"$ref":"#/$defs/adr"},"type":"array"},"boundaries":{"items":{"$ref":"#/$defs/boundary"},"type":"array"},"claims":{"items":{"$ref":"#/$defs/claim"},"type":"array"},"document_id_reservations":{"$ref":"#/$defs/documentIdReservations"},"evidence":{"items":{"$ref":"#/$defs/evidence"},"type":"array"},"features":{"items":{"$ref":"#/$defs/feature"},"type":"array"},"guard_policies":{"$ref":"#/$defs/guardPolicies"},"issues":{"items":{"$ref":"#/$defs/issue"},"type":"array"},"paths":{"$ref":"#/$defs/paths"},"profiles":{"items":{"$ref":"#/$defs/profile"},"type":"array"},"program":{"$ref":"#/$defs/program"},"releases":{"items":{"$ref":"#/$defs/release"},"type":"array"},"repo":{"$ref":"#/$defs/repo"},"risks":{"items":{"$ref":"#/$defs/risk"},"type":"array"},"schema_version":{"const":"0.6.0"},"specs":{"items":{"$ref":"#/$defs/spec"},"type":"array"},"tests":{"items":{"$ref":"#/$defs/test"},"type":"array"},"tooling":{"$ref":"#/$defs/tooling"}},"required":["schema_version","repo","tooling","paths","program","guard_policies","document_id_reservations","features","profiles","tests","claims","evidence","issues","risks","boundaries","releases","adrs","specs"],"title":"ssot-registry canonical registry","type":"object"}

ssot_contracts-0.2.18.dev1/src/ssot_contracts/templates/adr/ADR-0605-claim-status-vs-tier.yaml

@@ -0,0 +1,33 @@
+body: |-
+  ## Context
+  
+  Claims carry both lifecycle status and assurance tier. Earlier wording stated that status and tier are orthogonal, but the registry now also needs explicit promotion gates so a high lifecycle status cannot be mistaken for high assurance.
+  
+  ## Decision
+  
+  Claim status expresses lifecycle progression. Claim tier expresses assurance strength.
+  
+  Status values such as `asserted`, `evidenced`, `certified`, `promoted`, and `published` indicate where the claim sits in the registry workflow. They do not authorize stronger assurance language or a higher claim tier.
+  
+  Tier values `T0` through `T4` indicate what kind of proof supports the claim. A claim may only be treated as valid at a requested tier when the applicable claim tier gate passes.
+  
+  ## Consequences
+  
+  Automation and reviewers must not infer assurance strength from status alone. A claim with a high lifecycle status but insufficient tier-gate evidence must be reported as over-stated or blocked at the requested tier.
+  
+  Claim closure remains a support-coherence check. Tier gates remain the authority for the semantic meaning of `T1`, `T2`, `T3`, and `T4`.
+decision_date: null
+id: "adr:0605"
+kind: "adr"
+number: 605
+origin: "ssot-origin"
+references: []
+schema_version: "0.1.0"
+slug: "claim-status-vs-tier"
+status: "draft"
+status_notes: []
+summary: "Claim status expresses lifecycle progression, while claim tier expresses assurance strength and requires the applicable tier gate."
+superseded_by: []
+supersedes: []
+tags: []
+title: "Claim status and claim tier are orthogonal"

ssot_contracts-0.2.18.dev1/src/ssot_contracts/templates/adr/ADR-0615-downstream-assurance-language-ceilings.yaml

@@ -0,0 +1,62 @@
+body: |-
+  ## Context
+  
+  SSOT downstream repositories use feature target claim tiers, linked claims, tests, evidence, and tier gates to describe what a system can responsibly claim about a feature. The shared `T0` through `T4` tiers describe assurance strength, but downstream reports, release notes, README content, generated summaries, and certification artifacts also need a common language ceiling so weakly evidenced features are not described with stronger assurance language than their proof chains support.
+  
+  This ADR is an `ssot-origin` decision. It is intended to apply to downstream repositories that synchronize and conform to SSOT origin documents, not only to the `ssot-registry` package repository.
+  
+  ## Decision
+  
+  Downstream SSOT repositories must treat each feature's effective target claim tier as the ceiling for assurance language used in SSOT-controlled outputs. A feature may be described with language from its effective tier or any weaker tier. It must not be described with stronger language unless a linked claim passes claim-closure checks and the applicable claim tier gate at the stronger tier.
+  
+  The effective tier is resolved by the applicable evaluation policy. For direct feature evaluation, use `feature.plan.target_claim_tier`. For profile evaluation, use the feature target tier when present, otherwise the profile claim tier when the profile policy permits that fallback. If no effective tier can be resolved, downstream tooling must fail closed and must not emit assurance claims stronger than inventory-level language.
+  
+  Acceptable language by tier:
+  
+  | Tier | Assurance ceiling | Acceptable claims language |
+  |---|---|---|
+  | `T0` | Declared / Inventory | declared, tracked, intended, planned, in scope, inventoried |
+  | `T1` | Project Verified | project-verified, directly verified, verified by repeatable project-controlled tests, backed by project evidence |
+  | `T2` | Robustly Project Verified | robustly project-verified, verified across edge cases, verified across failure modes, verified across declared robustness dimensions |
+  | `T3` | Release Certified | release-certified, release-grade verified, certified for a named release, certified for a frozen boundary or profile |
+  | `T4` | Externally Certified | externally certified, independently reviewed, third-party validated, externally attested, validated by externally authored tests |
+  
+  Disallowed escalations:
+  
+  - `T0` features must not be described as implemented, working, verified, tested, robustly verified, certified, or externally validated.
+  - `T1` features must not be described as robustly verified, release-certified, or externally certified.
+  - `T2` features must not be described as release-certified or externally certified.
+  - `T3` features must not be described as externally certified, independently reviewed, or externally attested unless `T4` evidence exists.
+  
+  Canonical wording templates:
+  
+  - `T0`: Feature `<id>` is declared in scope for `<capability>`.
+  - `T1`: Feature `<id>` is project-verified for direct behavior `<capability>` by repeatable project-controlled checks.
+  - `T2`: Feature `<id>` is robustly project-verified for `<capability>` across `<robustness-dimensions>`.
+  - `T3`: Feature `<id>` is release-certified for `<release-or-boundary-or-profile>` with passing certification gates.
+  - `T4`: Feature `<id>` is externally certified for `<capability>` by `<external-source-or-artifact>`.
+  
+  Claim status remains orthogonal to claim tier. Status may describe lifecycle progress, but it does not authorize stronger assurance language. Evidence tier alignment, linked test status, feature target tier evaluation, and the applicable claim tier gate remain the enforcement mechanisms for whether stronger language is valid.
+  
+  ## Consequences
+  
+  Downstream generated summaries, READMEs, release notes, certification reports, review comments, and human-authored SSOT-controlled documentation must choose assurance language from the feature's effective tier or a weaker tier.
+  
+  Downstream projects may adopt stricter vocabulary, additional review gates, or domain-specific phrasing, but they must not permit stronger assurance wording than the feature's passing proof chain supports.
+  
+  Reviewers and automation should treat over-strong assurance language as a policy defect even when the underlying feature is implemented.
+decision_date: null
+id: "adr:0615"
+kind: "adr"
+number: 615
+origin: "ssot-origin"
+references: []
+schema_version: "0.2.0"
+slug: "downstream-assurance-language-ceilings"
+status: "accepted"
+status_notes: []
+summary: "SSOT downstream repositories use feature target claim tiers, linked claims, tests, evidence, and tier gates to control assurance language ceilings."
+superseded_by: []
+supersedes: []
+tags: []
+title: "Downstream assurance-language ceilings for feature target claim tiers"

{ssot_contracts-0.2.17.dev1 → ssot_contracts-0.2.18.dev1}/src/ssot_contracts/templates/adr/ADR-0616-out-of-bounds-implementation-disposition.yaml

@@ -40,7 +40,7 @@ schema_version: "0.2.0"
 slug: "out-of-bounds-implementation-disposition"
 status: "accepted"
 status_notes: []
-summary: "Non-absent out-of-bounds features must explicitly declare whether partial implementation is tolerated or prohibited."
+summary: "Feature implementation state, planning horizon, and lifecycle state are separate axes. That separation is useful, but it leaves an ambiguous case: a feature can be `out_of_bounds` while still being `partial` or `implemented` in the codebase."
 superseded_by: []
 supersedes: []
 tags: []

{ssot_contracts-0.2.17.dev1 → ssot_contracts-0.2.18.dev1}/src/ssot_contracts/templates/adr/ADR-0617-feature-implementation-claim-ceilings.yaml

@@ -1,31 +1,35 @@
 body: |-
   ## Context
-
+  
   Feature implementation status, claim lifecycle status, and claim assurance tier are separate fields. That separation is useful, but it can overstate implementation when a feature has multiple active linked claims and only one of them satisfies the target tier.
-
+  
   `T0` is inventory-level assurance. A `T0` claim records declared intent, scope, or placeholder support; it does not prove working behavior. Therefore a feature with an active required `T0` claim must not be marked `implemented`.
-
+  
   ## Decision
-
+  
   Feature implementation promotion is capped by active required linked claims.
-
+  
   All active linked claims on a feature are required for feature implementation closure. Retired claims are ignored. A stronger linked claim cannot override a weaker active required claim.
-
+  
   A feature may be marked `implemented` only when:
-
+  
   - linked tests pass,
   - required features are implemented,
   - every active required linked claim satisfies the feature's effective target tier,
   - no active required linked claim is `T0`.
-
+  
   If an active required `T0` claim is linked to a feature, the highest allowed feature `implementation_status` is `partial`. If all linked support is planned or placeholder-only, the highest allowed feature `implementation_status` is `absent`.
-
+  
+  Direct implementation and certification maturity are related but not identical. `T1` can establish direct implementation. `T2` can establish robust implementation. `T3` and `T4` establish release certification and external validation maturity unless a feature explicitly targets those tiers as its implementation bar.
+  
+  Active weaker claims continue to block feature implementation until they are retired or superseded. A stronger linked claim cannot hide an active weaker required claim.
+  
   ## Consequences
-
-  Automated status synchronization must use all-pass claim precedence for feature implementation promotion.
-
+  
+  Automated status synchronization must use all-pass claim precedence for feature implementation promotion and must respect claim tier gates when evaluating whether active claims satisfy a feature target tier.
+  
   Validation must reject manually edited registries that mark a feature `implemented` while an active required linked claim is `T0` or below the feature target tier.
-
+  
   Registries that need non-blocking explanatory claims must model that as a later governed schema capability. Until that exists, active linked claims are required closure inputs.
 decision_date: null
 id: "adr:0617"
@@ -37,7 +41,7 @@ schema_version: "0.2.0"
 slug: "feature-implementation-claim-ceilings"
 status: "accepted"
 status_notes: []
-summary: "Feature implementation promotion is capped by active required linked claims; active T0 claims keep features below implemented."
+summary: "Feature implementation status is capped by active required claims, while certification and external validation maturity remain distinct assurance layers."
 superseded_by: []
 supersedes: []
 tags: []

ssot_contracts-0.2.18.dev1/src/ssot_contracts/templates/adr/ADR-0618-local-release-assurance-remains-ssot-native.yaml

@@ -0,0 +1,35 @@
+schema_version: "0.3.0"
+kind: "adr"
+id: "adr:0618"
+number: 618
+slug: "local-release-assurance-remains-ssot-native"
+title: "Local Release Assurance Remains SSOT Native"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "Draft. This is a tentative proposal record, not an accepted implementation mandate."
+supersedes: []
+superseded_by: []
+status_notes:
+  -
+    status: "draft"
+    note: "Tentative local release assurance proposal; not accepted or implementation-bound."
+    at: "2026-05-08T07:33:02Z"
+references: []
+body: |-
+  ## Status
+  
+  Draft. This is a tentative proposal record, not an accepted implementation mandate.
+  
+  ## Context
+  
+  The registry already governs ADRs, SPECs, features, tests, claims, evidence, boundaries, releases, reports, and snapshots. We want to explore release-assurance capabilities without adding mandatory external services or build systems.
+  
+  ## Decision
+  
+  Keep local release assurance SSOT-native. Candidate capabilities must use existing registry data, local files, canonical JSON, SHA-256 hashes, validation reports, certification reports, and release gates. CUE, Bazel, Nix, Sigstore, Cosign, Rekor, Docker-only assumptions, network services, and mandatory external build tools are out of scope for the core proposal.
+  
+  ## Consequences
+  
+  The implementation can remain portable and dependency-light. Any future external integration must be optional and adapter-based, not part of the core assurance contract.

ssot_contracts-0.2.18.dev1/src/ssot_contracts/templates/adr/ADR-0619-content-addressed-governed-source-snapshots.yaml

@@ -0,0 +1,35 @@
+schema_version: "0.3.0"
+kind: "adr"
+id: "adr:0619"
+number: 619
+slug: "content-addressed-governed-source-snapshots"
+title: "Content Addressed Governed Source Snapshots"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "Draft. This records an exploratory direction for later feature rows."
+supersedes: []
+superseded_by: []
+status_notes:
+  -
+    status: "draft"
+    note: "Tentative local release assurance proposal; not accepted or implementation-bound."
+    at: "2026-05-08T07:34:02Z"
+references: []
+body: |-
+  ## Status
+  
+  Draft. This records an exploratory direction for later feature rows.
+  
+  ## Context
+  
+  Current SSOT validation hashes ADR and SPEC document bodies and release snapshots hash selected linked test and evidence paths. That does not yet provide a release-scoped source-state root over governed files.
+  
+  ## Decision
+  
+  Represent governed source state as deterministic file hashes plus a canonical root hash over the governed file hash map. The default scope should be declared or governed paths, not the entire repository. Full-repo hashing may be offered only as explicit opt-in policy.
+  
+  ## Consequences
+  
+  Release verification can detect drift across governed source, tests, evidence, documents, and artifacts while avoiding local cache, virtual environment, build-output, and temp-file noise.

ssot_contracts-0.2.18.dev1/src/ssot_contracts/templates/adr/ADR-0620-local-evidence-bundles-are-derived-release-artifacts.yaml

@@ -0,0 +1,35 @@
+schema_version: "0.3.0"
+kind: "adr"
+id: "adr:0620"
+number: 620
+slug: "local-evidence-bundles-are-derived-release-artifacts"
+title: "Local Evidence Bundles Are Derived Release Artifacts"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "Draft. This is a tentative proposal for future implementation."
+supersedes: []
+superseded_by: []
+status_notes:
+  -
+    status: "draft"
+    note: "Tentative local release assurance proposal; not accepted or implementation-bound."
+    at: "2026-05-08T07:34:02Z"
+references: []
+body: |-
+  ## Status
+  
+  Draft. This is a tentative proposal for future implementation.
+  
+  ## Context
+  
+  Claims, tests, evidence rows, boundaries, and releases already form a proof chain. Operators still lack a single local artifact that bundles the release proof with source snapshot and artifact manifest references.
+  
+  ## Decision
+  
+  Treat local evidence bundles as derived SSOT release artifacts. Bundles are generated from registry truth and linked files; they are not a second source of truth. They should be canonical JSON, locally hashable, locally verifiable, and safe to regenerate.
+  
+  ## Consequences
+  
+  Verification can consume a portable local bundle while the registry remains authoritative. Bundle drift is detected through canonical hashing and release gates rather than external signatures.

ssot_contracts-0.2.18.dev1/src/ssot_contracts/templates/adr/ADR-0621-general-rules-of-interpretation.yaml

@@ -0,0 +1,44 @@
+schema_version: "0.3.0"
+kind: "adr"
+id: "adr:0621"
+number: 621
+slug: "general-rules-of-interpretation"
+title: "General rules of interpretation govern SSOT meaning"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "SSOT governance relies on authored ADRs, authored SPECs, registry entities, generated projections, CLI summaries, evidence artifacts, and repository documentation. Those surfaces are intentionally different, but the repository does not yet have a general rule set for resolving interpretation questions across them."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  ## Context
+  
+  SSOT governance relies on authored ADRs, authored SPECs, registry entities, generated projections, CLI summaries, evidence artifacts, and repository documentation. Those surfaces are intentionally different, but the repository does not yet have a general rule set for resolving interpretation questions across them.
+  
+  Without a governed interpretation rule, readers and automation can over-weight generated views, treat draft proposals as binding, infer support from missing rows, or resolve ambiguous certification and release questions permissively.
+  
+  ## Decision
+  
+  SSOT governance SHALL use general rules of interpretation for authority, conflict resolution, normative language, projections, entity absence, and fail-closed release decisions.
+  
+  The rules are:
+  
+  - authored ADRs and SPECs govern intent, rationale, and normative requirements;
+  - `.ssot/registry.json` governs current machine-readable entity state and relationships;
+  - generated exports, reports, graphs, README tables, and CLI summaries are projections unless a SPEC explicitly declares a surface canonical;
+  - specific accepted rules narrow or override general accepted rules for their exact scope;
+  - accepted documents override draft documents;
+  - later documents override earlier documents only through explicit supersession or explicit scoped narrowing;
+  - absence of a governed row means absence of a governed assertion;
+  - ambiguity in conformance, certification, promotion, publication, and release gates is resolved fail-closed.
+  
+  ## Consequences
+  
+  Validation, synchronization, certification, and release tooling must not treat generated projections as independent authority when they disagree with authored documents or the canonical registry.
+  
+  Draft ADRs and SPECs may guide planning, but they must not create binding conformance requirements until accepted or otherwise promoted by the repository's governed lifecycle.
+  
+  Downstream projects may add stricter local rules, but they must not interpret missing, ambiguous, or projection-only data as stronger assurance than the originating SSOT registry supports.

ssot_contracts-0.2.18.dev1/src/ssot_contracts/templates/adr/ADR-0622-definitions-govern-ssot-vocabulary.yaml

@@ -0,0 +1,41 @@
+schema_version: "0.3.0"
+kind: "adr"
+id: "adr:0622"
+number: 622
+slug: "definitions-govern-ssot-vocabulary"
+title: "Definitions govern SSOT vocabulary"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "SSOT governance uses recurring terms across authored ADRs, authored SPECs, registry rows, CLI output, generated projections, evidence artifacts, releases, boundaries, and downstream conformance work. Those terms currently appear across many documents, but there is no single governed vocabulary authority."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  ## Context
+  
+  SSOT governance uses recurring terms across authored ADRs, authored SPECs, registry rows, CLI output, generated projections, evidence artifacts, releases, boundaries, and downstream conformance work. Those terms currently appear across many documents, but there is no single governed vocabulary authority.
+  
+  Without a definitions authority, readers and tools can interpret entity families, proof terms, lifecycle terms, projections, and assurance terms inconsistently. That weakens traceability and makes release or certification claims harder to audit.
+  
+  ## Decision
+  
+  SSOT vocabulary SHALL be governed by a dedicated definitions SPEC.
+  
+  Defined SSOT terms SHALL override informal usage in README files, generated reports, examples, comments, and downstream prose.
+  
+  Entity-family terms SHALL be interpreted according to the definitions SPEC unless a more specific accepted SPEC narrows a term for its own explicit scope.
+  
+  Undefined terms retain their ordinary technical meaning, but they SHALL NOT create conformance, certification, release, or implementation obligations by implication.
+  
+  Downstream repositories MAY add stricter local definitions, but they SHALL NOT redefine upstream SSOT terms to claim stronger assurance than the upstream registry, authored documents, claims, tests, and evidence support.
+  
+  ## Consequences
+  
+  New ADRs and SPECs should reuse defined terms where possible instead of creating parallel vocabulary.
+  
+  Definitions that affect validation, synchronization, conformance, release, or certification behavior must be added to the governed definitions SPEC or to a narrower accepted SPEC that states its scope.
+  
+  Generated projections and CLI summaries must not introduce authoritative definitions that do not exist in authored governance.

ssot_contracts-0.2.18.dev1/src/ssot_contracts/templates/adr/ADR-0625-claim-tier-gates-and-core-promotion.yaml

@@ -0,0 +1,44 @@
+schema_version: "0.4.0"
+kind: "adr"
+id: "adr:0625"
+number: 625
+slug: "claim-tier-gates-and-core-promotion"
+title: "Claim Tier Gates Govern Core Promotion"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "Claim tiers are used by features, profiles, releases, reports, and downstream assurance language. If tiers can be raised by label alone, downstream outputs can overstate assurance even when tests and evidence exist."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  ## Context
+  
+  Claim tiers are used by features, profiles, releases, reports, and downstream assurance language. If tiers can be raised by label alone, downstream outputs can overstate assurance even when tests and evidence exist.
+  
+  Optional orchestration extensions may later coordinate work, but tier semantics must be enforceable by core `ssot-registry` without those extensions.
+  
+  ## Decision
+  
+  Claim tier promotion is governed by machine-actionable tier gates in core `ssot-registry`.
+  
+  `T1` means project-verified direct behavior. `T2` means robust project verification. `T3` means release, boundary, or profile certification. `T4` means external validation authority.
+  
+  Claim closure remains separate from tier promotion. Closure checks whether linked features, tests, and evidence are coherent and passing. Tier gates check whether the requested assurance tier is semantically valid.
+  
+  Operators may use an explicit override path where policy allows it, but bypasses must be visible in results or reports and must not silently convert weak evidence into stronger assurance.
+  
+  ## Rejected Alternatives
+  
+  - Treating evidence tier labels as sufficient for claim promotion.
+  - Treating `T2` as merely more repeatable `T1`.
+  - Treating `T3` as a `T2` claim with a release id.
+  - Treating `T4` as internal self-attestation.
+  
+  ## Consequences
+  
+  Core CLI, API, validation, and status synchronization can enforce assurance semantics before optional orchestration extensions exist.
+  
+  Downstream repositories can rely on the tier ladder without adopting any optional orchestration model.

ssot_contracts-0.2.18.dev1/src/ssot_contracts/templates/adr/ADR-0626-externally-authored-validation-as-t4.yaml

@@ -0,0 +1,31 @@
+schema_version: "0.3.0"
+kind: "adr"
+id: "adr:0626"
+number: 626
+slug: "externally-authored-validation-as-t4"
+title: "Externally Authored Validation Can Satisfy T4"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "T4 requires external validation authority; externally authored validation may count even when executed internally if provenance, scope, and result are recorded."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  ## Context
+  
+  `T4` needs to represent external assurance rather than stronger project self-attestation. At the same time, many authoritative conformance suites, probe corpora, review artifacts, and certification checks can be executed locally while remaining externally authored or independently controlled.
+  
+  ## Decision
+  
+  `T4` requires external validation authority.
+  
+  Externally authored validation artifacts may satisfy `T4` even when executed internally, provided the evidence records source provenance, authorship or control, validation scope, target claims or features, and result.
+  
+  Using an external dependency internally is not `T4` by itself. Passing an externally authored conformance suite, receiving an independent review report, or carrying a third-party certification artifact can satisfy `T4` when the evidence contract is met.
+  
+  ## Consequences
+  
+  `T4` remains distinct from project-controlled robustness verification. Projects can still run external suites locally without losing the external-authority property, but they must preserve provenance and scope in evidence.