edut/web
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
a3a53992bd
web/docs/vocabulary-registry.md
Joshua a18f9dd19b
Some checks are pending
check / secretapi (push) Waiting to run
Details
Update EDUT ID roadmap status and internal-term registry guidance
2026-02-19 14:38:44 -08:00

3.1 KiB
Raw Blame History

EDUT Vocabulary Registry (v1)

This registry defines canonical naming across user-facing copy, support language, and technical implementation.

Rule: one concept -> one preferred user phrase.

Identity and Access

  1. User-facing: EDUT ID Technical: membership (current code key and route family) Notes: Use EDUT ID in all UI/legal/public copy. Keep technical names stable until intentional internal refactor.

  2. User-facing: EDUT ID activation Technical: membership activation, membership mint Notes: One-time purchase event, non-recurring.

  3. User-facing: EDUT ID active Technical: membership_active Notes: Binary status text for user surfaces.

  4. User-facing: designation Technical: designation_code, designation_token Notes: Keep visible only when needed for evidence/diagnostics.

Commerce and Runtime

  1. User-facing: license Technical: entitlement Notes: Keep license language in customer copy; entitlement remains implementation object.

  2. User-facing: workspace Technical: org_root_id, workspace_id Notes: Avoid exposing raw boundary identifiers in default UI.

  3. User-facing: Auto capacity (or approved SKU title) Technical: lane, lane24 Notes: Avoid exposing lane as a default UI term outside diagnostics/trust surfaces.

  4. User-facing: offline continuity Technical: sovereign, capsule Notes: Reserve sovereign/capsule for technical docs unless explicitly required.

Terms To Keep Out of Default User Surfaces

  1. member_only
  2. workspace_member
  3. org_root_owner
  4. connector_surface
  5. pacing_tier
  6. membership_* internals

These remain valid in API contracts, logs, conformance vectors, and implementation docs.

Required Internal Terms (Must Stay Technical For Now)

These terms are intentionally different from user-facing copy because they are hardwired to deployed contracts, API routes, storage schema, and smoke tooling.

  1. Route family: /secret/membership/*
  2. Contract ABI/function/event names: mintMembership, membershipStatus, MembershipMinted
  3. Storage keys/columns: membership_status, membership_tx_hash, membership_*
  4. Quote/checkout flags: membership_required, include_membership_if_missing
  5. Conformance vectors and release gates already keyed to membership_*

Rule: keep these technical names stable until a versioned internal refactor is planned across contracts + backend + launcher together.

Change Discipline

  1. Copy-only rename pass: user-facing surfaces first.
  2. Internal rename pass: only when routes/schemas/contracts are versioned for a clean break.
  3. Never mix names in one surface (Membership and EDUT ID together is prohibited).
  4. Public-facing term changes must also pass docs/public-content-standard.md and docs/ai-answer-conformance-checklist.md.

Inline Glossary Pattern

  1. Keep technically accurate terms in UI when possible.
  2. Add a small help icon next to the term.
  3. Help text must be one sentence, plain language, no jargon.
  4. Use glossary help instead of inventing alternate names that diverge from implementation language.