SAM is a working-draft proposal. Breaking changes are expected. The stable target is v1. We are actively asking for technical review, authoring feedback, citations, and validator implementations — not adoption commitments.
This document covers how to engage. The normative reference is v0.1/SPECIFICATION.md. Section numbers below refer to that document.
registry/standards.json and registry/tensions.json, or aliases for existing entries.Use the issue templates. Pick the one that matches:
standards.json or tensions.json entries.Blank issues are disabled. If your concern doesn’t fit a template, file under “Real-world feedback” and we’ll re-categorize.
For non-trivial schema changes, file an issue first. Schema changes affect every published manifest’s compatibility (per §6.3); discussion before code lowers the cost of getting it wrong.
Trivial fixes (typos, broken links, tightening a description without changing semantics) can come as direct PRs without a prior issue.
DCO sign-off is not required for v0. We will revisit if/when working-group adoption is on the table.
Every change touching sam/, registry/, or tools/ must pass the repo validator before commit.
# One-time setup
pip install jsonschema
# Run all checks (schema metaschema, every version's examples, conformance corpus, registries)
python3 tools/validate.py
The validator is also wired into:
.github/workflows/validate.yml runs on every push and pull request to main.An opt-in pre-commit hook — enable for your clone with:
git config core.hooksPath .githooks
The hook only runs the validator when you stage relevant files; bypass with git commit --no-verify only when you understand what you’re skipping.
Before requesting review, confirm:
python3 tools/validate.py passes locally/v0.1/ is the current published version (and frozen at its URIs once any consumer signs against it). Changes go to the next minor (v0.2 while MAJOR is 0) or the next major. Past versions remain at their URIs forever — that’s the same-MAJOR backward-compatibility promise (§6.3).
If you’re proposing a change that would break a v0.1 manifest, label your issue breaking and explain the migration path. Whether the change lands in v0.x or waits for v1.0 depends on how disruptive it is; expect a discussion.
This project adopts the Contributor Covenant 2.1. Be considerate; assume good faith; keep it about the work.
Security concerns about the spec, schema, or sample tooling go through SECURITY.md, not the public issue tracker.
Contributions to the schema, examples, conformance corpus, registries, or sample tooling are accepted under the Apache-2.0 license the rest of the code uses. Contributions to specification text, README, or other prose are accepted under the CC-BY-4.0 license for those files. Submitting a PR signals your acceptance of these terms.