Product Lifecycle and Resident Incubation

Draft 0.1 — 2 August 2026
Product lifecycle status is a network operating classification. It does not itself create ownership, employment, partnership, franchise, investment rights, certification, or legal approval.

Objective

ANUKA needs a repeatable way to admit, test, launch, improve, pause, transfer, and retire products without confusing enthusiasm with readiness.

The governing rule is:

A product earns deeper network integration by satisfying explicit evidence, operating, security, accessibility, governance, and continuity requirements.

Product lifecycle states

Observed

A product, service, community tool, or market need has been identified.

An observed record may contain:

public name and URL;
problem statement;
public evidence;
possible participants;
unresolved ownership or operator status;
unverified community notes.

Observed status does not imply affiliation.

Claimed

An authorized representative has claimed the product identity and established initial control of the product profile.

Minimum evidence:

organization or operator identity;
domain or repository control;
contact and security contact;
claim authority;
acceptance of current ANUKA terms for the claim flow.

Claimed status does not imply residency or quality verification.

Candidate

The product is being evaluated for ANUKA integration.

A Candidate has:

a named operator;
a defined problem and intended users;
an initial Product Charter;
a declared legal entity or responsible person;
preliminary technical and data architecture;
known risks and open questions;
a proposed incubation plan.

Candidate products may use public identity and documentation components but should not imply full network conformance.

Incubating

The product is actively implementing required capabilities and proving operating viability.

Incubation normally includes:

shared identity and consent integration;
canonical event and evidence contracts;
product governance setup;
security and privacy review;
accessibility review;
support and incident process;
initial opportunity and contribution loop;
launch-readiness evidence;
continuity and exit plan.

Incubating products receive bounded support and must publish their current gaps.

Resident

A Resident product has an accepted charter, a responsible operator, supported protocol versions, launch controls, and ongoing reporting obligations.

Resident status means:

the product may represent itself as an ANUKA Resident;
shared network services may be used under applicable agreements;
product opportunities and verified contributions may participate in the shared graph;
product governance and incident duties apply;
protocol exceptions remain visible.

Resident status is not a quality guarantee or government-style license.

Verified Resident

A Verified Resident has passed an explicit, versioned verification profile.

Verification may cover separate dimensions:

identity and authority;
security controls;
accessibility;
privacy and consent;
evidence integrity;
payment and ledger conformance;
reliability;
governance;
support;
product claims.

Verification must state exactly what was checked, against which version, by whom, when, and with what limitations.

Dormant

A product remains historically connected but is not actively meeting normal operating requirements.

Dormancy may result from:

no active operator;
extended inactivity;
support unavailability;
suspended payments;
unresolved critical risks;
planned seasonal pause;
transition or sale.

Dormant products must not display current verification as if active.

Exiting

The product is executing a documented exit, transfer, fork, sale, shutdown, or independent continuation plan.

The product remains subject to data, payment, security, notification, and record-preservation duties during transition.

Exited

The product no longer participates as a Resident.

Historical records remain accurate, while current affiliation claims are removed or clearly dated.

Admission principles

Admission decisions must consider:

alignment with protected principles;
identifiable operator and accountability;
legal and commercial clarity;
expected participant value;
feasibility of integration;
security and privacy risk;
accessibility implications;
financial and operational sustainability;
dependency and continuity risk;
potential harm or abuse;
whether the shared core is genuinely useful.

Admission is not based on founder charisma, social following, token ownership, or speculative valuation.

Product categories

A Candidate declares one or more categories:

independent SaaS product;
marketplace or exchange;
open-source tool;
internal shared service;
community application;
browser or site integration;
data or evidence provider;
AI-agent application;
research or experimental product;
public-benefit service.

Category influences review requirements but does not replace risk analysis.

Incubation tracks

Standard track

For products with ordinary identity, data, payment, and contribution needs.

Low-risk experimental track

For prototypes using synthetic or public data, no financial movement, no high-impact decisions, and a small participant group.

Regulated or high-impact track

For products involving areas such as:

employment or worker evaluation;
investment or securities-related activity;
lending or credit;
health or highly sensitive data;
minors;
money movement beyond approved marketplace flows;
legal decisions;
public-sector use;
biometric or government identity.

This track requires dedicated legal, security, privacy, and governance review before production use.

Infrastructure track

For shared services whose failure can affect multiple products.

Infrastructure Candidates require stronger reliability, access-control, change-management, and continuity evidence.

Incubation charter

Every Incubating product has an incubation charter containing:

product ID and name;
operator and legal entity;
founder or owner reserved powers;
Product Steward and accountable leads;
intended users and problem;
business model;
data classes;
payment flows;
supported jurisdictions;
shared-core capabilities requested;
protocol versions;
known exceptions;
required reviews;
milestones and target dates;
budget and funding;
success and stop criteria;
exit and handover plan.

Material changes create a new charter version.

Required evidence package

Before Resident admission, the product should provide:

current Product Charter;
system and data-flow diagram;
threat model;
privacy and consent inventory;
accessibility assessment;
security verification profile;
incident and support plan;
business continuity plan;
payment responsibility map where applicable;
operator and authority evidence;
dependency inventory;
launch-readiness report;
known limitations and exceptions;
public claims inventory.

The package may reference controlled evidence rather than publishing sensitive artifacts.

Incubation milestones

A typical sequence is:

M0 problem and operator validated
M1 charter and architecture accepted
M2 shared identity and consent connected
M3 evidence and observability working
M4 security, privacy, accessibility, and support gates passed
M5 controlled pilot completed
M6 resident admission decision
M7 post-launch review

Milestones are tailored to risk and product category.

Stage reviews

Each stage review records:

stage and date;
reviewers and conflicts;
evidence considered;
requirements passed;
open findings;
exceptions and expiry;
decision;
next milestone;
appeal path.

Possible decisions:

advance;
advance with conditions;
remain in stage;
pause;
return to earlier stage;
reject;
move to high-impact track;
begin exit.

Exception management

A product may request a time-limited exception when full conformance is not currently practical.

An exception states:

exact requirement;
reason;
risk;
affected users and systems;
compensating controls;
owner;
expiry;
remediation plan;
public disclosure level;
automatic consequences at expiry.

Exceptions cannot waive protected principles or legal obligations.

Pilot requirements

A controlled pilot should define:

eligible participants;
invitation and consent;
production or sandbox status;
data and payment limits;
feature flags;
support channel;
monitoring;
rollback conditions;
incident authority;
evaluation plan;
exit communication.

Pilot participants must not be misled into believing an experimental service is fully verified.

Resident admission decision

A Resident admission record includes:

charter version;
operator and legal owner;
supported protocol versions;
approved capabilities;
unresolved exceptions;
verification status by dimension;
jurisdictions and user restrictions;
launch date;
review date;
decision owner;
public summary.

The decision must be made by the authority defined in the Governance Architecture, not by an automated score alone.

Continuous residency

Residency is maintained through ongoing evidence, not a permanent badge.

A Resident must keep current:

operator and contact details;
security contact;
protocol versions;
incident readiness;
privacy and consent behavior;
payment configuration;
accessibility status;
support availability;
verification and exception status;
continuity plan.

Material changes can trigger re-review.

Periodic review

Review frequency depends on risk:

low-risk product: at least annually;
payment, identity, or sensitive-data product: at least semiannually;
critical shared service: quarterly operational review plus continuous monitoring;
after major incident, ownership transfer, or architecture change: event-driven review.

These are default directions, not legal compliance periods.

Status downgrade

Status may be downgraded for:

expired operator authority;
repeated SLO failure without remediation;
material security or privacy risk;
misleading affiliation or verification claims;
unsupported protocol versions;
unresolved payment obligations;
inaccessible core flows without an approved remediation plan;
absent support;
failure to complete required review;
voluntary pause.

Downgrade must follow notice and due process except where emergency containment is necessary.

Re-entry

An Exited or Dormant product may re-enter through a new review based on:

current operator;
current architecture;
current legal and product model;
resolved historical obligations;
current protocol compatibility;
current launch evidence.

Historical verification does not automatically revive.

Product registry

The public registry should expose:

product name and ID;
operator;
lifecycle status;
dates;
supported protocol versions;
verification dimensions;
current exceptions;
security and support contacts;
public charter;
affiliation statement;
exit or dormancy notice.

Restricted details remain in controlled records.

Anti-patterns

ANUKA must avoid:

admitting products through personal relationships alone;
granting permanent badges;
hiding unresolved exceptions;
treating revenue as proof of safety or quality;
forcing every product into identical architecture;
allowing a pilot to become production by inertia;
keeping an abandoned product marked active;
withholding product history during exit;
claiming certification without a defined program.

MVP acceptance criteria

lifecycle states are implemented in the registry;
every Candidate has an operator and charter;
Incubating products have milestones and stop criteria;
pilot status is visible;
Resident admission produces a durable decision record;
verification is dimension-specific and versioned;
exceptions expire automatically;
periodic review dates are tracked;
dormancy and exit are visible;
historical affiliation remains accurately dated.

Verification record

Lifecycle baseline checked: 2 August 2026
Current status: Product operating draft
Legal effect of lifecycle labels: None by themselves
Human admission decision: Required