Documentation Governance and Implementation Roadmap
Draft 0.1 — 2 August 2026 This roadmap is a delivery and disclosure framework. It is not a claim that the described network, assurance profiles, or shared services are already operating.
Objective
Section titled “Objective”ANUKA has a broad Foundation baseline. The next discipline is to make its implementation legible: begin with one useful product, release it safely, and publish evidence of what is actually true.
The governing rule is:
Documented intent never substitutes for a working, reviewed, and evidenced capability.
This roadmap connects the Foundation, identity, governance, shared-core, and product-lifecycle documents without treating the whole network as an MVP.
Truth states
Section titled “Truth states”Every public claim, protocol, capability, and product requirement uses one of these states.
Interactive implementation register
What a status actually proves
Select a state to distinguish a proposal from a running and independently checked capability.
Draft. A proposal under discussion; it makes no implementation promise.
Required public evidence Owner, version, and open questions.
Candidate. A scoped proposal ready for review or experiment.
Required public evidence Acceptance criteria, risks, and decision owner.
Ratified. A governing rule or specification formally accepted.
Required public evidence Decision record, effective version, and amendment path.
Implemented. Running code or operating practice exists in a stated environment.
Required public evidence Release reference, owner, and stated limitations.
Verified. A named check validated a particular implementation and scope.
Required public evidence Verifier, date, method, exceptions, and expiry.
Retired. No longer current; its history remains discoverable.
Required public evidence A successor or exit record.
| State | Meaning | Required public evidence |
|---|---|---|
| Draft | A proposal under discussion; it makes no implementation promise. | Owner, version, and open questions. |
| Candidate | A scoped proposal ready for review or experiment. | Acceptance criteria, risks, and decision owner. |
| Ratified | A governing rule or specification formally accepted. | Decision record, effective version, and amendment path. |
| Implemented | Running code or operating practice exists in a stated environment. | Release reference, owner, and stated limitations. |
| Verified | A named check validated a particular implementation and scope. | Verifier, date, method, exceptions, and expiry. |
| Retired | No longer current; its history remains discoverable. | A successor or exit record. |
Implemented is not Verified; Ratified is not a promise that a feature exists; and no status is a universal quality badge.
Delivery sequence
Section titled “Delivery sequence”Interactive roadmap
Build the smallest credible path first
Select a phase to see its concrete boundary before the next phase begins.
Phase 0 — Truth visible. Publish the status registry, document owners, version policy, and the first ADR backlog.
Gate Move on when public claims distinguish intent, implementation, and verification.
Read phase 0 in the roadmapPhase 1 — ANUKA Goals. Launch one private-by-default product with a promise that a person can understand on its own.
Gate Do not add marketplace, reputation, treasury, or agent scope to make the first journey useful.
Read phase 1 in the roadmapPhase 2 — Shared identity. Use auth.anuka.pro as the consent and login boundary for Goals through the narrow OAuth/OIDC profile.
Gate Authentication precedes cross-product linking, public identity graphs, and payment credentials.
Read phase 2 in the roadmapPhase 3 — Critical journey. Verify sign-in, private goal practice, recovery, export, deletion, accessibility, and support.
Gate Publish the named verification scope, exceptions, and expiry rather than a generic quality claim.
Read phase 3 in the roadmapPhase 4 — Earned reuse. Extract only shared capabilities that Goals has proven it needs, with an ADR and product exit path.
Gate Selective expansion begins only after the shared surface is stable, owned, and compatible.
Read phase 4 in the roadmapPhase 5 — Selective expansion. Additional products earn admission through their charter, risk classification, launch gates, and evidence.
Gate Payments, public reputation, agents, and evidence exchange remain separately gated.
Read phase 5 in the roadmapPhase 0 — make truth visible
Section titled “Phase 0 — make truth visible”Publish this roadmap, an implementation registry, named document owners, versioning policy, and a small ADR backlog. The Foundation remains the source of normative intent; the registry states whether each item is only drafted, ratified, implemented, or verified.
Phase 1 — launch one understandable product
Section titled “Phase 1 — launch one understandable product”Start with ANUKA Goals, not a general marketplace, reputation network, treasury, or agent platform. Its narrow job is to help a person create and maintain private goals and choose whether to share only the minimum necessary information. A user can understand the product without understanding the full ANUKA architecture.
Phase 2 — make identity reusable, not invasive
Section titled “Phase 2 — make identity reusable, not invasive”Use the OAuth/OIDC integration profile to make auth.anuka.pro the consent and login boundary for Goals. Deliver authentication before cross-product reputation, public identity graphs, payment credentials, or broad account linking.
Phase 3 — prove the critical journey
Section titled “Phase 3 — prove the critical journey”For the first product, verify the account creation/sign-in, goal creation, private-by-default data handling, export/deletion path, logout, recovery, accessibility, and support journey. Publish the exact verification scope and remaining exceptions.
Phase 4 — admit only earned reuse
Section titled “Phase 4 — admit only earned reuse”Extract a shared-core capability only after Goals has a stable, tested need. First candidates are client registration, consent records, session/identity handoff, and a minimal audit event shape. Each extraction needs an ADR, a named owner, compatibility policy, and a product exit path.
Phase 5 — selective expansion
Section titled “Phase 5 — selective expansion”Additional resident products are Candidates, not automatic tenants. They earn shared services through a charter, risk classification, launch gates, and evidence appropriate to their use. Payments, opportunities, evidence exchange, AI-agent delegation, and public reputation remain separately gated.
Initial dependency map
Section titled “Initial dependency map”Interactive first-release map
What the small first product depends on
Select a concern to see the bounded outcome it enables. Linked sources remain in the table below.
| Delivery concern | Foundation source | First practical outcome |
|---|---|---|
| voluntary, privacy-bound participation | 002 Principles and 026 Consent | private Goals data and explicit sharing choices |
| accountable access without universal identity proofing | 020 Identity | OAuth/OIDC account access at A1; no global verified label |
| independent product accountability | 061 Product Charter | versioned Goals charter, contacts, data and exit record |
| graduated admission and launch proof | 060 Lifecycle and 062 Quality Gates | Goals starts as Candidate/Incubating, not a Verified Resident |
| local autonomy with clear shared commitments | 044 Resident Governance | Goals retains product decisions; shared identity scope is declared |
| stable machine boundaries | 052 API & SDK Contracts | versioned client registration and narrow identity contracts |
ADR backlog
Section titled “ADR backlog”| ADR | Decision to make before broad reuse | Default until decided |
|---|---|---|
| ADR-001 | Public issuer and discovery URL strategy for OIDC | Do not advertise discovery as implemented. |
| ADR-002 | Token format, signing keys, rotation, and validation | Client-specific issuer/audience validation; no token sharing across products. |
| ADR-003 | OAuth client registration, redirect-URI verification, and owner review | Manual allowlisted registration for the first client. |
| ADR-004 | Identity subject and account-linking model | No automatic cross-product account or profile linking. |
| ADR-005 | Consent receipt, revocation, retention, and support access | Purpose-bound records and product-local data minimization. |
| ADR-006 | Shared audit-event minimum and retention | Log security-relevant metadata only; never goal content by default. |
Conformance checklist for a first Resident candidate
Section titled “Conformance checklist for a first Resident candidate”Before calling a product Resident, record at least:
- a current Product Charter, accountable operator, security/privacy/support contacts, and lifecycle status;
- its exact OAuth/OIDC client ID, allowed redirect URIs, scopes, logout and recovery behaviour;
- data inventory, retention, export, deletion/correction process, and consent boundaries;
- an accessibility review of the sign-in and core task journey;
- critical-journey tests, incident contact, status/communication route, and backup/restore expectation;
- public claims with evidence, known limitations, and a clear exit/transfer plan.
Ownership, release, and ratification
Section titled “Ownership, release, and ratification”Each document has a named steward. Changes to protected principles follow the Constitution; product implementation decisions stay with the product owner subject to declared shared commitments. Every release links its implementation record to the applicable spec version, tests/checks, and known limitations. A ratification record names the decision maker, version, effective date, review date, and amendment route.
The public landing page should eventually present a compact What is implemented today register sourced from those records. Until then, this roadmap and each product profile must say when an item is planned rather than live.
Measures and stop conditions
Section titled “Measures and stop conditions”The first release is successful when people can complete the private Goals journey reliably and understand what auth.anuka.pro is asking for. It is not successful because it has many sign-in providers, data fields, products, tokens, or public profiles.
Pause expansion when there is an unresolved security/privacy/accessibility issue on the critical journey, unclear ownership, an untested recovery/exit path, or a requested shared capability that has no product-proven need.