Contributing to the Standard

The Vinculum Standard evolves through proposals. Here's how to suggest and discuss changes.

Overview

The Standard is a collaborative specification for substrate memory — the typed-graph entry shape and the read/write/supersede/reason-on operations built on top of it. Changes, clarifications, and improvements are proposed, discussed, and adopted through a transparent process. Whether you're fixing a typo or proposing a new section, your contribution is welcome.

The process

1. Open a discussion

Before drafting a formal proposal, open a discussion in the Standard's issue tracker or discussion venue. Outline what you'd like to change and why. This gives the community a chance to weigh in early and helps avoid duplicate work.

2. Draft a proposal

Use the SEP template to structure your proposal. SEP stands for “Standard Enhancement Proposal” — it mirrors the format of other well-established specs (PEP, RFC, etc.) so reviewers and adopters have a familiar structure.

Your proposal should include: the motivation (why this change matters), the specification (what exactly you're proposing), the rationale (why this approach over alternatives), and any backwards-compatibility or security implications.

3. Share your draft

Post your draft proposal to the discussion venue. The community will review, ask questions, and suggest refinements. Be prepared to iterate and explain your reasoning.

4. Reach consensus

The goal is broad consensus, not unanimous approval. If the core maintainers and active community members agree the proposal improves the Standard, it moves forward.

5. Adoption

Once approved, your proposal is merged into the Standard. It becomes part of the canonical spec that new implementations reference.

What makes a good proposal?

• Clear motivation: explain the problem or gap your proposal addresses. Why does the Standard need this change?
• Concrete specification:be precise. “Cleaner API” is too vague; “add an optional timeout parameter to X, with a 500ms default” is clear.
• Consider alternatives:show why your approach is better than other options. Demonstrating you've thought through tradeoffs builds confidence.
• Backwards compatibility: will existing implementations break? Is there a migration path? Propose it.

Scope

The Standard covers the entry shape (id/type/content/author/created_at, links, metadata — see the entry schema), the core operations (read/write/supersede/reason-on), and conformance criteria for implementations. It does not prescribe:

• Implementation details (how one vendor builds their store)
• Branding or marketing copy
• Operational policies (e.g. how to configure hosting or auth)
• Vendor-specific extensions (those belong in vendor documentation)

If your proposal falls outside the Standard's scope, consider whether it belongs in an implementation guide, a vendor extension, or separate documentation instead.

Questions?

If you're unsure whether your idea is in scope, or how to get started, open an issue or discussion. The community is here to help.