Resident Product Governance

Draft 0.1 — 2 August 2026
Resident status is a network relationship. It does not automatically make a product a subsidiary, franchise, joint venture, security, certified provider, or product owned by an ANUKA legal entity.

Objective

ANUKA is designed as a portfolio and network of independently operated products rather than one monolithic application.

Resident governance must answer:

who controls the product;
which ANUKA protocols it uses;
what it promises participants;
which decisions remain local;
which shared rules apply;
how founders, stewards, customers, contributors, and investors influence decisions;
how the product changes status or exits;
how trust claims are verified and corrected.

The core rule is:

A resident product keeps local autonomy while making its network relationship, authority, exceptions, and evidence explicit.

Resident Product Charter

Every resident product must publish a versioned charter.

Minimum fields:

product_id: product:anuka:example
legal_operator: Example Product LLC
status: resident
charter_version: 0.1.0
network_constitution_version: 0.1.0-draft
shared_protocols:
  - presence: 0.1
  - passport: 0.1
  - consent: 0.1
  - economy: 0.1
product_founders:
  - participant:anuka:founder-1
product_council: council:example-product
reserved_powers:
  - trademark_assignment
  - equity_issuance
  - legal_entity_dissolution
public_governance_url: https://example.com/governance

The charter must identify:

product mission;
legal operator or explicit absence of one;
ownership and IP boundaries;
founder rights;
product council or decision-makers;
stewardship model;
supported network protocols;
public and private data policies;
marketplace and payment roles;
revenue and fee relationships;
user and contributor rights;
conflict and appeal routes;
shared network commitments;
declared exceptions;
exit and transition terms.

Product status lifecycle

Candidate

A product is exploring ANUKA integration but has no resident rights or endorsement.

Requirements:

basic identity record;
responsible operator;
initial risk classification;
no misleading resident claim.

Incubating

A product receives structured support while proving governance, product viability, security, and network alignment.

Possible support:

shared infrastructure;
mentoring;
contributor opportunities;
temporary grants;
design and architecture review;
limited network visibility.

Incubating does not imply certification or guaranteed admission.

Resident

A product has an approved charter and uses declared shared protocols.

Resident status means the relationship is official and current. It does not mean every product claim has been independently verified.

Verified Resident

A resident product has passed a named conformance or evidence program.

The interface must identify:

verified scope;
criteria version;
verifier;
evidence date;
expiry;
exceptions;
status and revocation method.

Restricted

Specific resident capabilities are temporarily limited due to security, payment, legal, conformance, or governance risk.

Restrictions must be scoped and reviewable.

Dormant

The product remains historically recognized but is not actively maintained or serving users.

Archived

The product is no longer operating under its previous mandate. Records remain available for history, obligations, and verification.

Exited

The product voluntarily leaves the network while satisfying transition duties.

Separated

The network ends resident status after due process or urgent risk containment.

Separation does not erase open-source rights or legitimate historical records.

Product autonomy

Resident products normally control:

product strategy;
features;
pricing;
customer selection;
product-specific contributor programs;
product operations;
product contracts;
hiring and work relationships;
product marketing;
local infrastructure;
local budgets;
optional protocol adoption.

Network governance may intervene only where a valid shared rule applies, such as:

false ANUKA affiliation claims;
misuse of network credentials;
shared-security risk;
shared-service abuse;
payment or marketplace violations;
privacy or consent protocol violations;
constitutional commitments adopted by the product;
trademark or certification terms;
cross-product harm.

Founder rights and reserved powers

A founder may retain declared reserved powers.

Examples:

changing the product mission;
approving equity issuance;
selling substantial assets;
assigning core trademarks;
appointing legal directors or managers;
dissolving the legal entity;
approving acquisition;
transferring product ownership.

Reserved powers must be:

publicly identified at an appropriate level;
legally valid where relevant;
separated from routine product governance;
reviewed for conflicts with participant promises;
subject to notice and transition rules.

A founder must not claim community governance while privately retaining undisclosed vetoes.

Product Council

A product may use a Product Council to govern roadmap and community matters.

Possible responsibilities:

roadmap principles;
stewardship appointments;
contributor programs;
public product policies;
product-level budget recommendations;
opportunity and bounty standards;
quality review;
community moderation;
product conformance.

The council charter must define whether decisions are:

binding on the product operator;
advisory;
binding only within a delegated budget;
subject to founder or legal-entity reserved powers;
subject to network protocol review.

Customer influence

Customers can influence products through:

feedback;
usage and retention;
advisory councils;
sponsored features;
pre-orders;
public proposals;
service-level agreements;
enterprise commitments;
customer-elected representatives where a product adopts that model.

Payment does not automatically create constitutional or ownership authority.

A sponsor may receive the deliverables promised in a sponsorship agreement but cannot secretly purchase unrelated access to personal data or governance.

Contributor influence

Contributors may earn contextual authority through demonstrated work.

Possible progression:

participant → contributor → reviewer → maintainer → steward → council member

Progression is not automatic and should consider:

contribution quality;
reliability;
collaboration;
security awareness;
product context;
conflicts;
willingness to accept accountability.

Merit in one product does not automatically transfer governance power to another.

Investor and owner influence

Equity holders, lenders, and legal owners have rights defined by law and legal instruments.

Product interfaces must distinguish:

legal ownership vote;
board or manager authority;
product council decision;
customer advisory signal;
contributor consensus;
network conformance decision.

These may influence each other but are not interchangeable.

Stewardship relationship

A product may delegate operations to a Product Steward.

The Stewardship Grant must state:

product scope;
strategic objective;
operational powers;
budget;
metrics;
reserved powers;
data access;
payment authority;
hiring or contracting authority, if any;
legal authority, if any;
start, review, and expiry;
compensation;
termination;
handover.

Product governance should review stewardship based on evidence, not personality or popularity.

Product decision classes

P0 — Routine local execution

Examples:

issue triage;
reversible copy updates;
scheduled dependency updates;
customer support operations.

P1 — Product policy

Examples:

pricing;
moderation rules;
feature prioritization;
product-level data retention;
contributor requirements.

P2 — Material product change

Examples:

major pivot;
breaking API change;
substantial pricing model change;
high-risk AI deployment;
new marketplace function;
major data-use expansion.

P3 — Reserved legal or ownership action

Examples:

equity issuance;
acquisition;
legal merger;
sale of core IP;
dissolution;
regulated-license decision.

The charter must identify decision-maker and review process for each class.

Protocol adoption and exceptions

A resident product declares each shared protocol as:

adopted;
adopted with extensions;
partially adopted;
temporarily exempted;
not applicable;
deprecated.

Exceptions must identify:

reason;
affected behavior;
risk;
user impact;
alternative control;
expiry or review date.

A product must not claim full conformance while hiding material exceptions.

Shared-service dependencies

Products using shared services must identify:

service owner;
service-level target;
data roles;
authentication and authorization;
pricing;
portability;
outage behavior;
termination and migration;
incident responsibility.

ANUKA should avoid creating one unavoidable central dependency for identity, reputation, payments, or governance.

Product budgets and treasuries

A resident product’s operating funds remain separate from ANUKA shared treasury unless a documented allocation or legal relationship exists.

Product governance must identify:

merchant of record;
legal owner of funds;
budget approvers;
payment provider;
reserves;
taxes;
contributor compensation;
network fees;
sponsorship funds;
refund authority.

A product council must not spend legal-entity funds without valid delegated authority.

Product governance records

Public records should include:

charter;
current roles;
major decisions;
protocol versions;
declared exceptions;
product status;
public conflicts;
sponsorship rules;
conformance claims;
exit or separation notices.

Private records may include:

security vulnerabilities;
personal data;
confidential customer information;
legal advice;
personnel matters;
acquisition negotiations.

Product health review

Resident products should undergo periodic review covering:

active operator;
governance activity;
protocol conformance;
security status;
user complaints;
unresolved disputes;
data and consent practices;
payment and marketplace risk;
stewardship status;
business viability;
misleading affiliation claims;
exit readiness.

The review may result in:

continued resident status;
verified status;
corrective plan;
narrowed capabilities;
dormancy;
separation review.

Separation process

Except for urgent containment, separation should include:

notice of the alleged breach or incompatibility;
evidence;
opportunity to respond;
corrective period where appropriate;
independent review for disputed facts;
reasoned decision;
appeal;
transition plan;
removal or correction of official affiliation;
preservation of historical records.

Urgent suspension may precede full review when shared security, payment, legal, or privacy risk is material.

Voluntary exit

A product may exit by:

notifying the network;
settling shared obligations;
revoking network credentials;
migrating or deleting data according to policy;
removing current affiliation claims;
publishing continuity information;
exporting portable records;
completing stewardship and vendor handovers.

The product may continue using open-source components under their licenses.

Trademark and brand boundaries

Resident status may permit defined ANUKA marks or statements.

A trademark policy should distinguish:

Built with ANUKA;
ANUKA Resident;
ANUKA Verified Resident;
compatibility claims;
historical affiliation;
independent forks.

Open source does not grant trademark rights.

Minimum resident MVP

Before admitting the first resident product, ANUKA should have:

charter template;
status lifecycle;
operator identity verification;
protocol adoption record;
product authority map;
sponsorship and payment roles;
consent and data policy;
complaint and appeal route;
exit checklist;
trademark language;
security contact;
product governance record page.

Sources

Verification record

Sources opened and checked: 2 August 2026
Resident program status: Design draft
Trademark policy required: Yes
Legal operator agreement required: Yes