attribution-campaign-context 0.1.0__tar.gz

attribution_campaign_context-0.1.0/.github/workflows/ci.yml

@@ -0,0 +1,27 @@
+name: CI
+
+on:
+  push:
+    branches:
+      - master
+  pull_request:
+    branches:
+      - master
+
+permissions:
+  contents: read
+
+jobs:
+  python-package-matrix:
+    uses: cobycloud/actions/.github/workflows/reusable-python-package-matrix-ci.yml@main
+    with:
+      python-versions: '["3.10","3.11","3.12","3.13"]'
+      package-cells: '[{"name":"attribution-campaign-context","path":"."}]'
+      install-command: uv sync --all-groups --frozen
+      compile-command: uv run python -m compileall src tests
+      test-command: uv run python -m pytest
+
+  ssot-validate:
+    uses: cobycloud/actions/.github/workflows/reusable-ssot-validate.yml@main
+    with:
+      validate-command: python -m pip install ssot-registry && python -m ssot_cli.main validate .

attribution_campaign_context-0.1.0/.github/workflows/publish.yml

@@ -0,0 +1,28 @@
+name: Publish
+
+on:
+  workflow_dispatch:
+
+permissions:
+  contents: read
+  id-token: write
+
+jobs:
+  pypi:
+    name: Publish to PyPI
+    runs-on: ubuntu-latest
+    environment: pypi
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: cobycloud/actions/actions/python-package-build@main
+        with:
+          python-version: "3.13"
+          project-path: "."
+          out-dir: dist
+          upload-artifact: "false"
+
+      - uses: cobycloud/actions/actions/pypi-publish@main
+        with:
+          packages-dir: dist
+          print-hash: "true"

attribution_campaign_context-0.1.0/.gitignore

@@ -0,0 +1,24 @@
+.venv/
+.uv-cache/
+__pycache__/
+*.py[cod]
+.pytest_cache/
+dist/
+build/
+*.egg-info/
+
+# Local generated caches and temporary package artifacts
+.tmp/
+.tmp*/
+tmp/
+.uv-cache*/
+.uv-python*/
+.venv*/
+.venv-gitvs*/
+generation_examples/
+node_modules/
+.mypy_cache/
+.ruff_cache/
+.tox/
+.nox/
+target/

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0600-canonical-json-registry.yaml

@@ -0,0 +1,17 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0600"
+number: 600
+slug: "canonical-json-registry"
+title: "Canonical registry is a single JSON document"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "The only authored machine-readable source of truth is `.ssot/registry.json`."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  The only authored machine-readable source of truth is `.ssot/registry.json`.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0601-features-are-targetable-units.yaml

@@ -0,0 +1,23 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0601"
+number: 601
+slug: "features-are-targetable-units"
+title: "Features are the targetable units"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "Features are the only targetable implementation units. There is no separate `targets[]` section."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  Features are the only targetable implementation units. There is no separate `targets[]` section.
+  
+  Because features are the targetable units, the default authoring path for new feature rows shall align with proof requirements. New `feature create` operations are expected to scaffold minimally valid proof-graph closure by default unless the operator explicitly disables that behavior.
+  
+  Feature inventory naming MAY use umbrella/leaf conventions when a repository needs grouped readability, but that convention is not a runtime dependency model. `feature.requires` is reserved for prerequisite features that must independently pass before the dependent feature can pass.
+  
+  Profiles remain the preferred grouped evaluation surface. Operators should not overload umbrella feature names to represent certification or bundle evaluation when a profile is the correct modeled unit.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0602-issues-are-plannable-work-items.yaml

@@ -0,0 +1,17 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0602"
+number: 602
+slug: "issues-are-plannable-work-items"
+title: "Issues are plannable work items"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "Issues and tickets can be planned as current, next, future, explicit, backlog, or out-of-bounds, but they are not substitute targets for features."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  Issues and tickets can be planned as current, next, future, explicit, backlog, or out-of-bounds, but they are not substitute targets for features.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0603-entity-centric-registry-derived-graph.yaml

@@ -0,0 +1,17 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0603"
+number: 603
+slug: "entity-centric-registry-derived-graph"
+title: "Entity-centric registry with a derived graph export"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "The canonical registry is entity-centric JSON with explicit references. A graph export is derived from it."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  The canonical registry is entity-centric JSON with explicit references. A graph export is derived from it.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0604-normalized-prefixed-ids.yaml

@@ -0,0 +1,17 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0604"
+number: 604
+slug: "normalized-prefixed-ids"
+title: "Normalized prefixed IDs"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "Every first-class entity uses a normalized prefixed ID."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  Every first-class entity uses a normalized prefixed ID.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0605-claim-status-vs-tier.yaml

@@ -0,0 +1,33 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0605"
+number: 605
+slug: "claim-status-vs-tier"
+title: "Claim status and claim tier are orthogonal"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "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."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+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`.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0606-feature-implementation-vs-lifecycle.yaml

@@ -0,0 +1,17 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0606"
+number: 606
+slug: "feature-implementation-vs-lifecycle"
+title: "Feature implementation state is separate from lifecycle state"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "`implementation_status` and `lifecycle.stage` are distinct fields."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  `implementation_status` and `lifecycle.stage` are distinct fields.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0607-immutable-boundary-and-release-snapshots.yaml

@@ -0,0 +1,17 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0607"
+number: 607
+slug: "immutable-boundary-and-release-snapshots"
+title: "Immutable boundary and release snapshots"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "Frozen boundaries and promoted/published releases emit immutable snapshots with hashes."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  Frozen boundaries and promoted/published releases emit immutable snapshots with hashes.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0608-fail-closed-guards.yaml

@@ -0,0 +1,17 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0608"
+number: 608
+slug: "fail-closed-guards"
+title: "Fail-closed guards"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "Validation, certification, promotion, publication, and lifecycle transitions refuse to proceed on guard violations."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  Validation, certification, promotion, publication, and lifecycle transitions refuse to proceed on guard violations.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0609-generated-projections-are-non-canonical.yaml

@@ -0,0 +1,32 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0609"
+number: 609
+slug: "generated-projections-are-non-canonical"
+title: "Generated projections are non-canonical"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "This is an `ssot-origin` ADR copied into downstream SSOT repositories."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  This is an `ssot-origin` ADR copied into downstream SSOT repositories.
+  
+  In an operator repository, canonical authored SSOT content lives under `.ssot/`:
+  
+  - `.ssot/registry.json`,
+  - repo-local ADRs under `.ssot/adr/`,
+  - repo-local specs under `.ssot/specs/`.
+  
+  Packaged `ssot-origin` ADRs/specs provide baseline policy, but operators do not edit those synced copies directly.
+  
+  Generated projections include:
+  
+  - graph exports,
+  - reports and snapshots,
+  - rendered or exported representations such as CSV, YAML, TOML, DOT, PNG, and SVG,
+  - mirrored or regenerated documentation derived from the canonical SSOT content.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0610-explicit-schema-versioning.yaml

@@ -0,0 +1,17 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0610"
+number: 610
+slug: "explicit-schema-versioning"
+title: "Explicit schema versioning"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "Breaking schema changes increment `schema_version` and require migration."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  Breaking schema changes increment `schema_version` and require migration.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0611-portable-core-repo-specific-evidence-adapters.yaml

@@ -0,0 +1,17 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0611"
+number: 611
+slug: "portable-core-repo-specific-evidence-adapters"
+title: "Portable SSOT core with repo-specific evidence adapters"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "The SSOT core contract governs and validates the registry graph. Repository-specific evidence generation is implemented outside the core (or through adapters) per repository."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  The SSOT core contract governs and validates the registry graph. Repository-specific evidence generation is implemented outside the core (or through adapters) per repository.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0612-ssot-path-and-filename-length-limits.yaml

@@ -0,0 +1,22 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0612"
+number: 612
+slug: "ssot-path-and-filename-length-limits"
+title: "Enforce max path and filename lengths under `.ssot`"
+status: "draft"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "Files under `.ssot` MUST respect these limits:"
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  Files under `.ssot` MUST respect these limits:
+  
+  - Maximum relative path length: **240** characters.
+  - Maximum filename length: **120** characters.
+  
+  Validation fails when either limit is exceeded.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0613-profiles-as-reusable-feature-bundles.yaml

@@ -0,0 +1,41 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0613"
+number: 613
+slug: "profiles-as-reusable-feature-bundles"
+title: "Profiles are reusable feature bundles with derived pass status"
+status: "accepted"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "The registry needed an entity between atomic features and release boundaries:"
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  ## Context
+  
+  The registry needed an entity between atomic features and release boundaries:
+  
+  - features are independently targetable,
+  - boundaries are release/freeze artifacts,
+  - releases certify a boundary scope.
+  
+  Teams also need reusable capability bundles that can be composed and evaluated.
+  
+  ## Decision
+  
+  Introduce a first-class `profiles` entity:
+  
+  - profile rows bundle `feature_ids` and nested `profile_ids`,
+  - profile pass/fail is computed (never stored),
+  - feature pass still requires satisfying claims and guard checks,
+  - boundary scope may include both direct `feature_ids` and `profile_ids`,
+  - boundary feature scope is resolved dynamically at evaluation/reporting time.
+  
+  Tier resolution is fail-closed:
+  
+  1. feature `plan.target_claim_tier`,
+  2. profile `claim_tier`,
+  3. no tier => failing evaluation.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0614-specs-own-typed-adr-links.yaml

@@ -0,0 +1,17 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0614"
+number: 614
+slug: "specs-own-typed-adr-links"
+title: "SPECs own typed ADR links"
+status: "accepted"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "SPEC documents own typed ADR references. Features continue to reference SPECs only. Feature-to-ADR visibility is derived transitively through feature.spec_ids -> spec.adr_ids. This is a breaking schema-model change that requires a schema_version bump and migration support."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  SPEC documents own typed ADR references. Features continue to reference SPECs only. Feature-to-ADR visibility is derived transitively through feature.spec_ids -> spec.adr_ids. This is a breaking schema-model change that requires a schema_version bump and migration support.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0615-downstream-assurance-language-ceilings.yaml

@@ -0,0 +1,62 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0615"
+number: 615
+slug: "downstream-assurance-language-ceilings"
+title: "Downstream assurance-language ceilings for feature target claim tiers"
+status: "accepted"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+summary: "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."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+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.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0616-out-of-bounds-implementation-disposition.yaml

@@ -0,0 +1,47 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0616"
+number: 616
+slug: "out-of-bounds-implementation-disposition"
+title: "Out-of-bounds implementation disposition is explicit"
+status: "accepted"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+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."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+body: |-
+  ## Context
+  
+  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.
+  
+  That ambiguity matters because there are two different governance meanings:
+  
+  - partial support may be incidental and acceptable as non-targeted behavior,
+  - partial support may be prohibited and require removal, quarantine, or a release-blocking follow-up.
+  
+  ## Decision
+  
+  SSOT core records the distinction on the feature planning record as `plan.out_of_bounds_disposition`.
+  
+  Allowed values are:
+  
+  - `tolerated`: non-absent implementation exists but is accepted as non-targeted, non-certified, out-of-bounds behavior.
+  - `prohibited`: non-absent implementation exists and is not acceptable; removal or quarantine is required.
+  
+  For any feature where `plan.horizon == out_of_bounds` and `implementation_status` is `partial` or `implemented`, the disposition must be explicit.
+  
+  Tolerated out-of-bounds features must not be included in active boundaries and must carry a lifecycle note explaining the non-targeted status.
+  
+  Prohibited out-of-bounds features must target lifecycle `removed` and, while non-absent, must be tied to an open release-blocking issue or active release-blocking risk.
+  
+  ## Consequences
+  
+  Downstream registries cannot silently carry ambiguous out-of-bounds partial support.
+  
+  Release and certification workflows can distinguish acceptable non-target behavior from prohibited implementation leakage.
+  
+  A removed feature still requires `implementation_status: absent`; `prohibited` is the managed transition state while code or behavior remains present.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0617-feature-implementation-claim-ceilings.yaml

@@ -0,0 +1,48 @@
+schema_version: "0.7.0"
+kind: "adr"
+id: "adr:0617"
+number: 617
+slug: "feature-implementation-claim-ceilings"
+title: "Feature implementation is capped by active required claims"
+status: "accepted"
+origin: "ssot-origin"
+decision_date: null
+tags: []
+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."
+supersedes: []
+superseded_by: []
+status_notes: []
+references: []
+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 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.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0618-local-release-assurance-remains-ssot-native.yaml

@@ -0,0 +1,35 @@
+schema_version: "0.7.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:
+  -
+    at: "2026-05-08T07:33:02Z"
+    note: "Tentative local release assurance proposal; not accepted or implementation-bound."
+    status: "draft"
+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.

attribution_campaign_context-0.1.0/.ssot/adr/ADR-0619-content-addressed-governed-source-snapshots.yaml

@@ -0,0 +1,35 @@
+schema_version: "0.7.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:
+  -
+    at: "2026-05-08T07:34:02Z"
+    note: "Tentative local release assurance proposal; not accepted or implementation-bound."
+    status: "draft"
+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.