How to contribute

How to contribute to Elimi Docs

Audience: all contributors
Status: building
Owns: docs / delivery lead
Depends on: Domain entities, Maturity

This site is the single source of truth. Lower layers reference the domain and lifecycle; they never invent parallel names for the same concepts.

Ownership

Doc area	Primary owner	Reviewers
Domain / glossary / lifecycle	Product + backend	UX, QA
Experience (flows, personas)	UX	Frontend, tech writing
OpenAPI / API contract	Backend	Frontend, QA
Backend architecture	Backend	Product
Frontend structure	Frontend	UX
Test cases	QA	Product
Feature narrative	Tech writing	Product, UX
Maturity / ecosystem map	Delivery or product lead	Leadership (occasional)

Rule: one owner writes; others only link and challenge language.

Status values

Align page status with Ecosystem maturity:

Status	Meaning
idea	Named; not specified for build
specced	Enough docs for implementation to start
building	Implementation in progress
alpha / beta / ga	Increasing production readiness

Put status in the page header block (and optionally frontmatter) so readiness is visible without reading Delivery.

Page header block

Every durable page should open with:

**Audience:** leadership | domain | ux | backend | frontend | qa | writing
**Status:** idea | specced | building | alpha | beta | ga
**Owns:** role or named owner
**Depends on:** links to domain / lifecycle / API / UX as relevant

Cross-link policy

From	Must link to
UX flow	Domain entity + lifecycle stage
OpenAPI / API group	Domain use case
Frontend area / component	UX screen + API
Test case	Lifecycle transition or policy
Feature brief	Experience + product module

Broken or missing links usually mean missing agreement—fix language first.

Page templates

Entity (domain)

• Name, one-sentence definition
• Key attributes (business, not DB columns)
• Invariants / rules
• Related entities and lifecycle stages

Flow (experience)

• Persona, goal, entry point
• Steps named with lifecycle stage / status codes
• Screens (or placeholders)
• Links to domain entities and policies

API operation group

• Resource group name (e.g. Applications)
• Domain use cases covered
• Point to future openapi.yaml paths when they exist
• Error / auth notes at a high level

Backend context

• Bounded context name
• Aggregates / entities owned
• Adapters (NIN, payment, Orchestrator, LMS)
• Links to API overview

Frontend area

• Route / app area
• Reusable components used
• Links to UX flows + API groups (no duplicate lifecycle tables)

Test case (QA)

ID: TC-…
Given: stage X / status Y (and persona)
When: …
Then: …
Refs: lifecycle / policy / flow links

Feature brief (narrative)

• Audience (candidate, centre, public, …)
• Draft / Review / Published
• What the feature does in plain language
• Links to experience + product modules

CAP RPL as the template

When LMS, WorkMasters, or Orchestrator leave stub status, copy the CAP RPL layer folders:

experience/ · api/ · backend/ · frontend/ · qa/ · narrative/

plus the shared product spine (overview, lifecycle or equivalent, policies, personas).