Product Charter and Onboarding

Draft 0.1 — 2 August 2026
A Product Charter is an operating record. It is not a substitute for incorporation documents, contracts, privacy notices, employment agreements, payment terms, or regulated licenses.

Objective

A product should not enter the network as an attractive landing page plus a cloud account nobody fully understands.

The Product Charter makes the operating truth explicit:

• who is accountable;
• what the product does;
• who it serves;
• which entity owns and operates it;
• what data and money move through it;
• which ANUKA capabilities it uses;
• who may change it;
• how it is supported;
• how it can be transferred or shut down.

Charter principles

A charter must be:

• specific enough to assign responsibility;
• current enough to guide operations;
• versioned;
• readable by non-engineers;
• linked to deeper evidence;
• explicit about unknowns;
• honest about legal and product boundaries;
• approved by the actual accountable authority.

A charter must not become a 90-page ceremonial document nobody updates.

Required charter sections

Identity

• Product ID;
• product name and aliases;
• domains and applications;
• repositories;
• current lifecycle state;
• public description;
• intended user groups;
• jurisdictions served;
• launch environments.

Operator and legal responsibility

• operating legal entity or responsible individual;
• entity jurisdiction and registration where applicable;
• product owner;
• founder reserved powers;
• Product Steward;
• security contact;
• privacy contact;
• payments and tax contact;
• support owner;
• emergency contact;
• authority evidence.

The charter must distinguish legal ownership, operational stewardship, repository control, domain control, and economic participation.

Purpose and product boundary

• user problem;
• intended outcomes;
• product scope;
• excluded use cases;
• high-impact uses;
• user promises;
• current limitations;
• business model;
• relationship to other products.

Users and stakeholders

• primary users;
• paying customers;
• contributors;
• sponsors;
• investors or diligence recipients;
• administrators;
• support personnel;
• external providers;
• affected non-users.

Product capabilities

The charter lists capabilities offered to users, such as:

• public profile;
• feedback;
• opportunity marketplace;
• contribution submission;
• sponsored features;
• payments;
• credentials;
• data-room access;
• AI-agent actions;
• analytics;
• notifications;
• governance participation.

Every capability maps to permissions, data classes, risks, support, and owner.

Shared-core dependencies

For each shared service:

• service name;
• purpose;
• protocol version;
• data exchanged;
• capabilities granted;
• failure behavior;
• fallback;
• support owner;
• exit or migration plan.

Architecture summary

The charter links to:

• system context diagram;
• deployment topology;
• trust boundaries;
• data-flow diagram;
• dependency inventory;
• storage systems;
• external providers;
• event and API contracts;
• environments;
• disaster-recovery profile.

Data inventory

For each major data category:

• purpose;
• subjects;
• source;
• classification;
• storage;
• processor or recipient;
• retention;
• consent or authority;
• deletion, correction, or revocation behavior;
• public or private status;
• model-provider use.

Payment and value flows

Where relevant:

• merchant of record;
• payer;
• recipient;
• platform fee;
• processor;
• charge model;
• refund owner;
• dispute loss bearer;
• tax responsibility;
• reserve policy;
• payout timing;
• ledger accounts;
• prohibited financial interpretations.

Governance

• decision owners;
• founder reserved powers;
• Product Council if any;
• roadmap authority;
• budget authority;
• release authority;
• incident authority;
• data-publication authority;
• stewardship grants;
• conflict rules;
• escalation and appeal;
• amendment process.

Security and privacy

• threat model owner and review date;
• security baseline;
• authentication profile;
• authorization model;
• secrets management;
• vulnerability intake;
• incident plan;
• privacy notice owner;
• consent flows;
• data-subject or participant request process;
• restricted-data handling;
• audit evidence.

Accessibility checklist

• target conformance profile;
• critical user journeys;
• assistive-technology testing plan;
• known barriers;
• accommodation or alternative process;
• owner;
• review date.

Reliability and support

• critical services;
• user journeys;
• SLIs and SLOs;
• support hours and channels;
• severity definitions;
• status page or incident channel;
• escalation path;
• backup and restore profile;
• business continuity owner.

Metrics and experiments

• product North Star and guardrails;
• event taxonomy;
• analytics providers;
• consent behavior;
• experiment authority;
• feature-flag provider;
• exposure logging;
• metric contracts;
• retention and access.

Claims

A public-claims inventory lists:

• claim text;
• audience;
• evidence owner;
• evidence reference;
• review date;
• permitted wording;
• expiry;
• correction path.

Continuity and exit

• operator replacement;
• domain and repository transfer;
• key recovery;
• data export;
• customer notice;
• outstanding payments;
• contributor evidence preservation;
• vendor exit;
• product shutdown;
• archival and trademark handling.

Charter metadata

Each charter has:

Record at a glance

Charter metadata

Field	Example value	Why it matters
charter_product_example_v3 · product_example	Stable charter and product identifiers.
v3.0.0 · approved	Current approved record.
2 Aug 2026	When this charter applies.
principal_example · product.owner	Authority that approved it.
1 Nov 2026	Scheduled review point.
charter_product_example_v2	Previous version retained for history.

Ownership map

The charter should include a compact ownership matrix.

Accountability map

Product charter ownership map

A compact RACI view makes the accountable party visible before a product reaches a pilot or production gate.

Area	A	R	C	I
Product strategy	Product Owner	Product Steward	Product Council	Residents
Production release	Release Owner	Engineering Lead	Security	Support
Privacy notice	Legal operator	Privacy Lead	Security, Product	Users
Refund policy	Merchant	Finance Lead	Support, Legal	Customers
Critical incident	Operator	Incident Commander	Security, Providers	Affected users

A accountable · R responsible · C consulted · I informed

The matrix does not replace legal authority documents.

Onboarding phases

Interactive growth flow

Product onboarding progress

A product moves forward only when its current phase has the required accountable evidence; a phase is not a guarantee of admission.

Legend: select a numbered step to read its description.

1 Discovery 2 Charter draft 3 Authority verification 4 Technical connection 5 Operating review 6 Controlled pilot 7 Admission

Step 1. Initial profile, operator candidate, lifecycle category, risk screen and decision to proceed.

1. Initial profile, operator candidate, lifecycle category, risk screen and decision to proceed.
2. Core charter records knowns, unknowns and their required resolution path.
3. Control of identity, domains, repos, entities, data and deployment is checked.
4. Shared-core boundaries and required integrations are made explicit.
5. Product, legal, privacy, security, support and continuity evidence is reviewed.
6. The product runs a bounded pilot with declared learning and stop conditions.
7. An accountable decision records status, conditions, exceptions and next review.

Phase 1 — Discovery

Outputs:

• initial product profile;
• operator candidate;
• lifecycle category;
• risk screen;
• initial shared-core fit;
• decision to proceed, pause, or decline.

Phase 2 — Charter draft

The product completes the core charter and declares unknowns.

Unknowns are categorized:

• must resolve before pilot;
• may resolve during pilot;
• accepted limitation;
• requires legal or specialist review;
• out of scope.

Phase 3 — Authority verification

Verify control of:

• product identity;
• domains;
• repositories;
• relevant legal entity;
• payment processor account;
• data sources;
• signing or deployment authority.

Phase 4 — Technical connection

Connect in a sandbox:

• identity;
• consent;
• project registry;
• events;
• observability;
• evidence;
• webhooks;
• SDK or MCP profile;
• feature flags.

Phase 5 — Operating review

Review:

• governance;
• support;
• security;
• privacy;
• accessibility;
• claims;
• continuity;
• payment model;
• experiment policy.

Phase 6 — Controlled pilot

Use bounded users, data, money, and capabilities.

Phase 7 — Admission

Create the Resident decision record and publish the permitted profile.

Onboarding checklist

Business and operator

• product problem and intended users documented;
• operator identified;
• legal owner or responsible person identified;
• founder rights documented;
• Product Steward identified or explicitly absent;
• business model documented;
• jurisdictions declared;
• public claims inventoried.

Technical

• repositories and environments inventoried;
• architecture and data-flow diagrams exist;
• shared-core versions selected;
• sandbox integration works;
• API and event contracts validated;
• observability is connected;
• rollback and feature-flag mechanisms exist;
• secrets are not stored in documentation or client bundles.

Identity and consent

• account and organization roles mapped;
• authorization capabilities defined;
• consent requests are granular;
• verifier access is visible and revocable;
• AI-agent access has a principal and task boundary;
• recovery and exit paths exist.

Data and privacy

• data inventory completed;
• classifications assigned;
• retention defined;
• processors and recipients named;
• public/private boundaries defined;
• deletion, correction, and revocation behavior documented;
• analytics consent behavior tested;
• restricted data excluded or reviewed.

Security

• threat model reviewed;
• authentication and authorization tested;
• dependency and supply-chain controls enabled;
• ASVS profile selected;
• vulnerability disclosure path exists;
• incident response roles assigned;
• backup and restore test completed where required;
• security contact is reachable.

Accessibility

• critical journeys identified;
• WCAG target selected;
• automated checks run;
• keyboard testing completed;
• screen-reader testing completed for critical journeys;
• accessible authentication reviewed;
• known barriers documented;
• accessibility contact exists.

Payments

• merchant and processor roles defined;
• charge model selected;
• fees and refund control documented;
• dispute loss bearer documented;
• tax responsibilities documented;
• ledger mapping verified;
• payout and reserve behavior tested;
• prohibited investment or escrow claims excluded.

Support and reliability

• service owner and support owner assigned;
• support channels work;
• severity levels documented;
• initial SLOs approved;
• error-budget behavior defined;
• status communication path exists;
• on-call or escalation process exists;
• continuity owner assigned.

Governance and continuity

• decision rights documented;
• conflicts and recusal process exists;
• emergency authority is bounded;
• charter review date exists;
• ownership-transfer process exists;
• product shutdown plan exists;
• participant export path exists;
• affiliation removal behavior exists.

Evidence links

Checklist completion must link to evidence, not rely on self-asserted checkboxes.

Evidence may include:

• tests;
• screenshots;
• signed decisions;
• configuration digests;
• runbooks;
• restore-test reports;
• contracts or controlled legal records;
• provider account verification;
• accessibility test reports;
• threat-model records;
• incident exercises;
• sandbox execution traces.

Change control

A charter update is required when there is a material change in:

• operator or legal owner;
• product purpose;
• high-impact use;
• payment model;
• data categories;
• AI autonomy;
• protocol versions;
• critical providers;
• founder reserved powers;
• jurisdiction;
• shutdown or transfer plan.

A material change may trigger a new launch review.

Public charter versus controlled annex

The public charter should include:

• purpose;
• operator;
• lifecycle status;
• governance summary;
• supported protocols;
• verification and exceptions;
• privacy, accessibility, security, and support contacts;
• affiliation and exit terms.

A controlled annex may include:

• sensitive architecture;
• private contracts;
• credentials;
• provider account details;
• security findings;
• restricted data maps;
• personal contact information.

Anti-patterns

• copying a generic template without real owners;
• naming a founder as owner of everything indefinitely;
• treating a repository admin as legal authority;
• hiding payment responsibility behind Stripe;
• saying “GDPR compliant” or “secure” without a defined basis;
• checking accessibility through automation only;
• onboarding production before sandbox and rollback work;
• leaving continuity until a founder disappears;
• using the charter as marketing copy.

Acceptance criteria

• every product has one current charter;
• every material area has an accountable owner;
• legal, operational, technical, and economic authority are distinguished;
• shared-core dependencies and protocol versions are declared;
• data and money flows are documented;
• security, privacy, accessibility, and support evidence exists;
• unknowns are visible and classified;
• checklist items link to evidence;
• material changes trigger charter review;
• public and controlled charter views are separated;
• transfer and shutdown paths exist before launch.

Related documents

• 060 — Product Lifecycle and Resident Incubation
• 044 — Resident Product Governance
• 050 — Shared Core Architecture
• 062 — Launch Readiness and Quality Gates

Verification record

• Charter baseline checked: 2 August 2026
• Checklist status: Draft
• Evidence-linked completion: Required
• Public charter safety review: Required