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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: ssot-contracts
-Version: 0.2.17.dev1
+Version: 0.2.17.dev2
 Summary: Canonical schemas, templates, manifests, and generated Python contract artifacts for SSOT.
 Author-email: Jacob Stewart <jacob@swarmauri.com>
 License-Expression: Apache-2.0

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

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "ssot-contracts"
-version = "0.2.17.dev1"
+version = "0.2.17.dev2"
 description = "Canonical schemas, templates, manifests, and generated Python contract artifacts for SSOT."
 readme = "README.md"
 requires-python = ">=3.10,<3.14"

{ssot_contracts-0.2.17.dev1 → ssot_contracts-0.2.17.dev2}/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.17.dev2}/src/ssot_contracts/templates/adr/ADR-0617-feature-implementation-claim-ceilings.yaml

@@ -1,31 +1,31 @@
 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`.
-
+  
   ## Consequences
-
+  
   Automated status synchronization must use all-pass claim precedence for feature implementation promotion.
-
+  
   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 +37,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, 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."
 superseded_by: []
 supersedes: []
 tags: []

ssot_contracts-0.2.17.dev2/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.17.dev2/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.17.dev2/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.17.dev2/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.17.dev2/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.17.dev1 → ssot_contracts-0.2.17.dev2}/src/ssot_contracts/templates/adr/manifest.json

@@ -294,7 +294,7 @@
     "title": "Out-of-bounds implementation disposition is explicit",
     "filename": "ADR-0616-out-of-bounds-implementation-disposition.yaml",
     "target_path": ".ssot/adr/ADR-0616-out-of-bounds-implementation-disposition.yaml",
-    "sha256": "62327f52cab47a338956d630fc43f5ed3981467b3c1072876a9f955e62a37d86",
+    "sha256": "d598e42994b2401e93b3c23b3c0095ed24b45ef257ead6689dc476bb273350d3",
     "origin": "ssot-origin",
     "reservation_owner": "ssot-origin",
     "immutable": true,
@@ -312,7 +312,7 @@
     "title": "Feature implementation is capped by active required claims",
     "filename": "ADR-0617-feature-implementation-claim-ceilings.yaml",
     "target_path": ".ssot/adr/ADR-0617-feature-implementation-claim-ceilings.yaml",
-    "sha256": "1e21944c47759757773e66f5bbfaae8801a33bca966c69772d3a31543062078e",
+    "sha256": "0a11198e91bb7e4e6027fbb4824798d784e5b15a9e39a58464ff1fdcb219ced5",
     "origin": "ssot-origin",
     "reservation_owner": "ssot-origin",
     "immutable": true,
@@ -322,5 +322,113 @@
     "supersedes": [],
     "superseded_by": [],
     "status_notes": []
+  },
+  {
+    "id": "adr:0618",
+    "number": 618,
+    "slug": "local-release-assurance-remains-ssot-native",
+    "title": "Local Release Assurance Remains SSOT Native",
+    "filename": "ADR-0618-local-release-assurance-remains-ssot-native.yaml",
+    "target_path": ".ssot/adr/ADR-0618-local-release-assurance-remains-ssot-native.yaml",
+    "sha256": "1fcf1d69ab68ae5e125b0f3bb7f6369240164c4a18b8e686479408bfd282587c",
+    "origin": "ssot-origin",
+    "reservation_owner": "ssot-origin",
+    "immutable": true,
+    "minimum_schema_version": "0.4.0",
+    "introduced_in": "0.2.10",
+    "status": "draft",
+    "supersedes": [],
+    "superseded_by": [],
+    "status_notes": [
+      {
+        "at": "2026-05-08T07:33:02Z",
+        "note": "Tentative local release assurance proposal; not accepted or implementation-bound.",
+        "status": "draft"
+      }
+    ]
+  },
+  {
+    "id": "adr:0619",
+    "number": 619,
+    "slug": "content-addressed-governed-source-snapshots",
+    "title": "Content Addressed Governed Source Snapshots",
+    "filename": "ADR-0619-content-addressed-governed-source-snapshots.yaml",
+    "target_path": ".ssot/adr/ADR-0619-content-addressed-governed-source-snapshots.yaml",
+    "sha256": "3e356168e16d0a4e63288c32a21af6c6e96bf7e92bd124ea796a3fc7e1cc6f9f",
+    "origin": "ssot-origin",
+    "reservation_owner": "ssot-origin",
+    "immutable": true,
+    "minimum_schema_version": "0.4.0",
+    "introduced_in": "0.2.10",
+    "status": "draft",
+    "supersedes": [],
+    "superseded_by": [],
+    "status_notes": [
+      {
+        "at": "2026-05-08T07:34:02Z",
+        "note": "Tentative local release assurance proposal; not accepted or implementation-bound.",
+        "status": "draft"
+      }
+    ]
+  },
+  {
+    "id": "adr:0620",
+    "number": 620,
+    "slug": "local-evidence-bundles-are-derived-release-artifacts",
+    "title": "Local Evidence Bundles Are Derived Release Artifacts",
+    "filename": "ADR-0620-local-evidence-bundles-are-derived-release-artifacts.yaml",
+    "target_path": ".ssot/adr/ADR-0620-local-evidence-bundles-are-derived-release-artifacts.yaml",
+    "sha256": "6bd56ffd4ccdab5d939757fedb1b0c6df9e8dc8c4d0811b0855e84cc8c936ae3",
+    "origin": "ssot-origin",
+    "reservation_owner": "ssot-origin",
+    "immutable": true,
+    "minimum_schema_version": "0.4.0",
+    "introduced_in": "0.2.10",
+    "status": "draft",
+    "supersedes": [],
+    "superseded_by": [],
+    "status_notes": [
+      {
+        "at": "2026-05-08T07:34:02Z",
+        "note": "Tentative local release assurance proposal; not accepted or implementation-bound.",
+        "status": "draft"
+      }
+    ]
+  },
+  {
+    "id": "adr:0621",
+    "number": 621,
+    "slug": "general-rules-of-interpretation",
+    "title": "General rules of interpretation govern SSOT meaning",
+    "filename": "ADR-0621-general-rules-of-interpretation.yaml",
+    "target_path": ".ssot/adr/ADR-0621-general-rules-of-interpretation.yaml",
+    "sha256": "20c89d5a323835e4dee328e4debbc8de0edf623f0b297e8158d0e8295f8157a9",
+    "origin": "ssot-origin",
+    "reservation_owner": "ssot-origin",
+    "immutable": true,
+    "minimum_schema_version": "0.4.0",
+    "introduced_in": "0.2.10",
+    "status": "draft",
+    "supersedes": [],
+    "superseded_by": [],
+    "status_notes": []
+  },
+  {
+    "id": "adr:0622",
+    "number": 622,
+    "slug": "definitions-govern-ssot-vocabulary",
+    "title": "Definitions govern SSOT vocabulary",
+    "filename": "ADR-0622-definitions-govern-ssot-vocabulary.yaml",
+    "target_path": ".ssot/adr/ADR-0622-definitions-govern-ssot-vocabulary.yaml",
+    "sha256": "816d194bcbbdf5f4bad1e8ab78e6756103f414554e0cc2a4c525a3697eee188d",
+    "origin": "ssot-origin",
+    "reservation_owner": "ssot-origin",
+    "immutable": true,
+    "minimum_schema_version": "0.4.0",
+    "introduced_in": "0.2.10",
+    "status": "draft",
+    "supersedes": [],
+    "superseded_by": [],
+    "status_notes": []
   }
 ]

{ssot_contracts-0.2.17.dev1 → ssot_contracts-0.2.17.dev2}/src/ssot_contracts/templates/specs/SPEC-0601-cli.yaml

@@ -1,4 +1,18 @@
-adr_ids: []
+schema_version: "0.3.0"
+kind: "spec"
+id: "spc:0601"
+number: 601
+slug: "cli"
+title: "CLI"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "Primary distribution: `ssot-cli`"
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
 body: |-
   Primary distribution: `ssot-cli`
   
@@ -26,6 +40,11 @@ body: |-
   - `ssot-registry release revoke`
   - `ssot-registry graph export`
   
+  Root metadata flags:
+  - `ssot --version`, `ssot-cli --version`, and `ssot-registry --version` SHALL print the installed CLI package version and exit successfully without requiring a subcommand.
+  - The reported version SHALL be resolved from installed Python package metadata for `ssot-cli`.
+  - Root version handling SHALL run before subcommand dispatch so it works even though normal CLI execution requires a subcommand.
+  
   ADR and SPEC authoring commands SHALL support two body source flags:
   - `--body`
   - `--body-file`
@@ -36,19 +55,16 @@ body: |-
   - create and update commands SHALL reject requests that provide both `--body` and `--body-file`
   
   CLI body flags SHALL map directly onto the corresponding runtime document mutation inputs.
-decision_date: null
-id: "spc:0601"
-kind: "spec"
-number: 601
-origin: "ssot-origin"
-references: []
-schema_version: "0.1.0"
-slug: "cli"
+  
+  Entity create and update commands for `feature`, `test`, `issue`, `boundary`, `profile`, `claim`, `evidence`, `risk`, and `release` SHALL also support two body source flags:
+  - `--body`
+  - `--body-file`
+  
+  Entity CLI source-selection rules:
+  - entity `create` commands MAY omit both `--body` and `--body-file`
+  - entity `update` commands MAY omit both `--body` and `--body-file`
+  - entity `create` and `update` commands SHALL reject requests that provide both `--body` and `--body-file`
+  - when `--body` is provided, the entity row `body` field SHALL be set from the inline UTF-8 text
+  - when `--body-file` is provided, the entity row `body` field SHALL be set from the referenced UTF-8 text file
 spec_kind: "operational"
-status: "draft"
-status_notes: []
-summary: "Primary distribution: `ssot-cli`"
-superseded_by: []
-supersedes: []
-tags: []
-title: "CLI"
+adr_ids: []

{ssot_contracts-0.2.17.dev1 → ssot_contracts-0.2.17.dev2}/src/ssot_contracts/templates/specs/SPEC-0614-profile-evaluation-and-boundary-resolution.yaml

@@ -12,7 +12,7 @@ body: |-
   
   Profile row fields:
   
-  - `id`, `title`, `description`, `status`, `kind`
+  - `id`, `title`, `description`, `body`, `status`, `kind`
   - `feature_ids: list[str]`
   - `profile_ids: list[str]`
   - `claim_tier: T0..T4 | null`
@@ -21,6 +21,7 @@ body: |-
   
   Boundary rows include:
   
+  - `body: str | null`
   - `feature_ids: list[str]`
   - `profile_ids: list[str]`
   

{ssot_contracts-0.2.17.dev1 → ssot_contracts-0.2.17.dev2}/src/ssot_contracts/templates/specs/SPEC-0616-out-of-bounds-implementation-disposition.yaml

@@ -44,7 +44,7 @@ slug: "out-of-bounds-implementation-disposition"
 spec_kind: "normative"
 status: "accepted"
 status_notes: []
-summary: "Feature plans support explicit disposition for non-absent out-of-bounds implementation."
+summary: "Feature `plan` MAY include:"
 superseded_by: []
 supersedes: []
 tags: []

{ssot_contracts-0.2.17.dev1 → ssot_contracts-0.2.17.dev2}/src/ssot_contracts/templates/specs/SPEC-0617-feature-implementation-claim-ceilings.yaml

@@ -2,38 +2,38 @@ adr_ids:
   - "adr:0617"
 body: |-
   ## Overview
-
+  
   Feature implementation status SHALL be derived and validated through active required claim ceilings.
-
+  
   ## Active Required Claims
-
+  
   For feature implementation closure, active required claims are all linked `feature.claim_ids` whose claim status is not `retired`.
-
+  
   Until a first-class non-blocking claim role exists, every non-retired linked claim SHALL be treated as required for feature implementation closure.
-
+  
   ## Implementation Status Derivation
-
+  
   Automated status synchronization SHALL set a feature to `implemented` only when:
-
+  
   1. the feature has at least one active required linked claim,
   2. every active required linked claim has a tier other than `T0`,
   3. every active required linked claim is at or above the feature's `plan.target_claim_tier` when that target is present,
   4. every active required linked claim has status `evidenced` or higher after claim synchronization,
   5. every linked test is `passing`,
   6. every required feature is `implemented`.
-
+  
   If any active required linked claim is `T0`, the feature SHALL NOT be synchronized to `implemented`; the highest synchronized status is `partial` unless all support is planned or placeholder-only.
-
+  
   If a feature has mixed active required claims and any one of them fails the closure requirements, the feature SHALL NOT be synchronized to `implemented`.
-
+  
   ## Validation
-
+  
   Registry validation SHALL reject a feature with `implementation_status: implemented` when any active required linked claim is `T0` or below the feature's target claim tier.
-
+  
   Claim lifecycle status normalization remains the responsibility of automated status synchronization.
-
+  
   ## Profile Evaluation
-
+  
   Profile and boundary-oriented feature evaluation SHALL use the same all-active-required-claims precedence. A feature with an active required `T0` claim SHALL fail feature-pass evaluation even if another linked claim is stronger.
 decision_date: null
 id: "spc:0617"
@@ -46,7 +46,7 @@ slug: "feature-implementation-claim-ceilings"
 spec_kind: "normative"
 status: "accepted"
 status_notes: []
-summary: "Feature implementation status is derived and validated through active required claim ceilings."
+summary: "Feature implementation status SHALL be derived and validated through active required claim ceilings."
 superseded_by: []
 supersedes: []
 tags: []

ssot_contracts-0.2.17.dev2/src/ssot_contracts/templates/specs/SPEC-0618-local-release-assurance-candidate-scope.yaml

@@ -0,0 +1,38 @@
+schema_version: "0.3.0"
+kind: "spec"
+id: "spc:0618"
+number: 618
+slug: "local-release-assurance-candidate-scope"
+title: "Local Release Assurance Candidate Scope"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "Draft candidate scope."
+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 candidate scope.
+  
+  ## Scope
+  
+  This SPEC defines the exploratory local release assurance scope. The candidate surface includes governed source snapshots, deterministic root hashes, local evidence bundles, output artifact manifests, local verification reports, tamper detection, and release gate integration.
+  
+  ## Out Of Scope
+  
+  Mandatory CUE, Bazel, Nix, Sigstore, Cosign, Rekor, Docker-only artifact handling, network services, and required external build systems are out of scope. Optional adapters may be proposed separately later.
+  
+  ## Tentative Nature
+  
+  Rows linked to this SPEC should remain draft, absent, backlog, or future until implementation and proof chains exist.
+spec_kind: "governance"
+adr_ids:
+  - "adr:0618"

ssot_contracts-0.2.17.dev2/src/ssot_contracts/templates/specs/SPEC-0619-governed-source-snapshot-contract.yaml

@@ -0,0 +1,39 @@
+schema_version: "0.3.0"
+kind: "spec"
+id: "spc:0619"
+number: 619
+slug: "governed-source-snapshot-contract"
+title: "Governed Source Snapshot Contract"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "Draft contract."
+supersedes: []
+superseded_by: []
+status_notes:
+  -
+    status: "draft"
+    note: "Tentative local release assurance proposal; not accepted or implementation-bound."
+    at: "2026-05-08T07:34:03Z"
+references: []
+body: |-
+  ## Status
+  
+  Draft contract.
+  
+  ## Contract
+  
+  A governed source snapshot records a release id, path policy mode, included paths, excluded paths, file SHA-256 hashes, generated timestamp, registry path, registry hash, and deterministic source root hash.
+  
+  ## Path Policy Modes
+  
+  The proposed modes are ssot-only, declared, governed, and full-repo. The default should be declared or governed. Full-repo mode is explicit opt-in only.
+  
+  ## Validation
+  
+  Validation recomputes file hashes, rejects missing governed files, enforces canonical ordering, and recomputes the root hash.
+spec_kind: "operational"
+adr_ids:
+  - "adr:0618"
+  - "adr:0619"