The Global Registry · Draft v0.3 · August 2, 2026

Contributing to the Global Registry

This file ships with the registry's public repository when it opens; until then it documents exactly how contributions will work. The pledge in §7 is a draft awaiting counsel. No binding instrument exists yet. This page says so.

1 · Introduction

The Global Registry is KISOP's public dictionary: numbered concepts rendered in every language we can verify. The number is the term; words are renderings of it. Builders reference numbers; people see words in their own language. An accountable human reviewer attests to each verified entry. The public record uses that person's chosen public name or contributor ID. This page explains how a contribution becomes part of that record.

The plain-language overview lives on the registry page; the working rules and design notes ship with the repository.

2 · Architecture

terms-registry/
├── terms/K-*.yaml              # one canonical file per term — THE TRUTH
├── languages.yaml              # the numbered language index (columns) — canonical
├── compile_global_registry.py  # compiler: truth in → views out
├── GLOBAL-REGISTRY.md / .csv   # generated views — never edit by hand
├── packs/                      # per-language builder packs (planned) — never edit
└── CONTRIBUTING.md             # this file

The rule is simple: you edit the term files; the compiler rebuilds everything else. GLOBAL-REGISTRY.md and .csv are built from the term files, so never edit them by hand. To change something you see in those tables, change the term file it came from and run the compiler again.

3 · License

The registry is intended to be free for every person, forever — downloadable whole, every verification signed and public. Counsel is still deciding which open-license instrument to use. There is no license attached yet. Contributions are accepted under the forward-looking pledge in §7, which exists precisely so that the eventual license can cover every contribution cleanly. When the instrument is chosen, this section will name it, dated, and the pledge will reference it directly.

4 · Artifacts

ArtifactWhat it isStatus
terms/K-*.yamlThe canonical term filesLive — 9 seed terms, EN + ES
GLOBAL-REGISTRY.mdThe whole registry as one table (terms × numbered languages, verification visible)Live — generated
GLOBAL-REGISTRY.csvThe same, one column set per language, for spreadsheet verifiersLive — generated
Public registry pagePlain-language overview + in-browser CSV/JSON downloadLive, in review
packs/Per-language packs for builders (accepted terms only; machine translations stay clearly labeled until a human verifies them)Planned
EditionsImmutable quarterly snapshots a tool can pin to, so meaning stays stable across a lifetimeDesigned, not yet cut
Public repositoryThe registry's permanent open home — files, history, contributionsPlanned, not yet live

5 · Contributions

Four kinds of contribution, in rising order of effort. Until the public repository opens, all four arrive through one door: Write to us → “feedback” on the main site. This section describes the file mechanics your contribution lands in either way.

5.1 Verify a rendering — the fifteen-minute contribution

The most valuable thing a bilingual professional can do here.

  1. Pick a term file in terms/, in a language you live in.
  2. Read the rendering aloud. Fix anything a real person wouldn't say — label, definition, example.
  3. Check the reading level: a child in early grade school should follow the definition.
  4. Check culture: is there a warning that protects people (see K-100006, the notario case)? Add it if so.
  5. In that language's block, set:
    confidence: verified
    reviewed_by: "Contributor ID · public name or anonymous · language relationship · YYYY-MM-DD"
  6. Rerun python3 compile_global_registry.py — your signature now appears in the table's Verified column and the verification ledger.

Your language relationship explains why you can review the wording: for example, “grew up speaking Spanish in New Mexico,” “certified translator,” “bilingual clinician,” “community elder,” or “native-speaking teacher.” It is different from identity proofing and from a professional license. Contributors choose whether their public name, contributor ID, or “anonymous” appears. A license is listed only when the review requires one and its status has been checked.

5.2 Propose a term

  1. Copy any existing term file as a template.
  2. Give it a provisional id: KX-<yourname>-001. Never use a K- number. Permanent numbers are assigned from a single counter on acceptance. Contributors never mint them.
  3. Set status: proposed.
  4. Fill at least one language completely (label, plain definition at reading level, example sentence). “No term without a sentence.” Every term must be needed by something real.
  5. Say where the need came from: the document, form, or conversation that lacked this word.

“I don't have a word for this” is itself a contribution. Send it as a problem flag (§5.3) if you can't draft the term yourself.

5.3 Flag a problem

“That word is wrong where I live” is a contribution. Include:

5.4 Add a language

A new language is a new numbered column, registered once in languages.yaml with the next L-number, then filled term by term. Language numbers are never reused and carry no rank. Every language needs an accountable steward who reviews entries or recruits reviewers. The public record may identify that steward by a chosen public name or contributor ID; KISOP may privately confirm identity when the work is consequential. Diaspora communities and institutions can fund a language's drafting and review; the result is released to everyone, forever. Stay with the column after you add it. A half-filled column with a responsible steward and visible gaps beats a complete column no one maintains.

5.5 Code and tooling

The registry's code is small by design: a compiler turns term files into published tables, and later tools will build the per-language packs. It is written in Python; the only outside library is PyYAML. Everything else comes with Python.

Three rules for that code:

  1. Same input, same output: byte for byte. Run the compiler twice on the same term files and you get identical results: no randomness, no timestamps. That way, any change in a published table always traces back to a change someone signed.
  2. Never edit generated files by hand. Fix the term file instead, then run the compiler again.
  3. Unknown languages fail loudly. If a term file uses a language that isn't registered in languages.yaml, the compiler warns you. It never publishes that file without saying so.

Code changes carry the same sign-off line as any other contribution.

6 · The rules that are not negotiable

  1. Numbers are never reused and never deleted. A wrong term is deprecated with a superseded_by pointer.
  2. No meaning is ever encoded in a number — not category, not language, not rank.
  3. Users never see numbers. People see words; numbers are plumbing.
  4. Every term keeps a plain definition at second-to-third-grade reading level — that is the floor, verified per rendering. Verification is never assumed from the English. Definitions for more expert readers can be added as they are written and verified; the plain one always remains.
  5. The culture: field is consumer protection. Warnings that protect people ride inside the term itself.
  6. Nothing is asserted from memory without a label. Unverified claims carry “verify before publishing” in notes:.
  7. Anonymous proposals and problem reports are accepted. A contribution may enter review without a public name. Canonical registry changes still require publication consent, provenance, and the appropriate named or account-authenticated reviewers described in §7.

7 · Identity, attribution, and signing

A public name, account authentication, identity proofing, credential checking, and language review answer different questions. The Contribution and identity page defines those levels for the whole site.

A proposal may be anonymous. Someone may suggest a term, language example, reading, or correction without publishing a legal name. Anonymous proposals do not become verified language merely because they were submitted.

A verifier's attestation answers “what language, community, and meaning did this person review?” The record names the scope, date, account, and any specific credential that was checked. Ordinary language knowledge may come from a native speaker, heritage speaker, translator, teacher, clinician, caregiver, community elder, or another stated relationship to the language. Consequential medical, legal, financial, consent, safety, and emergency language requires two independent language reviews plus steward review.

Publication consent answers “may the registry carry and license this work?” It is recorded separately from public attribution and private contact information. A public record may use a name, pseudonym, contributor id, or “Anonymous contributor,” according to the contributor's choice.

A cryptographic signature proves control of a signing key, not a legal identity or credential. Signed commits remain useful provenance for repository changes, but KISOP does not present a Git signature as proof of a person's real-world claims.

Before publication, the contributor or authorized steward certifies the Registry Contribution Pledge, v0.2 — DRAFT, pending counsel:

(a) The contribution is my own work, or I have the right to submit it; if it carries someone else's words — a community's usage, a quoted phrase — I have said so.

(b) I understand the registry is intended to be released to everyone under an open license that keeps it free for every person, forever. I license my contribution for release under that instrument when it is attached, and for the registry's public availability in the meantime.

(c) I understand that an accepted contribution and its public attribution are kept in the registry's history and may be redistributed with the registry. My private contact information is not published automatically. The final policy will explain account deletion, correction, withdrawal before publication, and requests for later de-attribution.

(d) If I have reviewed a rendering, I have accurately described my relationship to that language and community. Any credential I claim is real and mine.

The registry's trust model is human accountability with precise labels: who proposed the words, who reviewed their use in a named community, what identity or credential was checked, who published the change, and what the record does not prove.

8 · What happens after you submit

  1. Every contribution gets a response. The team is small, so the timeline we give you is a real one.
  2. Renderings are reviewed by the language's owner (for Spanish today: the founder, verifier #1). Verification flips the mark to ✅ with your name; disagreements are resolved by native speakers, on the record.
  3. Proposed terms are checked against the dedupe rule (search before mint), given their real-sentence test, and on acceptance receive the next permanent K- number. Rejected proposals stay in history with the reasoning: a “no” is documentation too.
  4. Problem flags that touch safety (culture: candidates) are handled first.
  5. Attribution follows the published choice. A name, pseudonym, contributor id, or anonymous credit stays with the public record unless the final de-attribution policy provides another path. Private contact information does not appear in that record.

9 · Questions

The registry page answers the plain-language questions (what this is, downloads, rights). Everything else: Write to us → “feedback”. When the repository opens, issues live there and this section will say so, dated.

We look forward to your words — in every language you live in.

This page mirrors the repository's CONTRIBUTING.md, draft v0.3 (August 2, 2026; first published July 17, 2026). When the public repository opens, the file that ships with it is the working copy and this page will say so, dated.