Product Stewardship Protocol

Draft 0.1 — 2 August 2026
Stewardship is a protocol term for bounded operational authority. It does not by itself create employment, equity, officer status, fiduciary duty, partnership, franchise, agency, or ownership.

Objective

ANUKA should allow capable participants to take meaningful responsibility for products without forcing every relationship into permanent employment or founder ownership.

A product can temporarily grant a steward authority to improve a defined area, while preserving:

ownership rights;
legal governance;
customer obligations;
security boundaries;
financial controls;
continuity when the steward changes.

Stewardship is therefore not take over the company. It is:

A versioned grant of specific powers, resources, duties, limits, metrics, and accountability for a defined period.

Stewardship objects

Product mandate

A durable statement of:

product purpose;
customer promise;
legal owner or operator;
protected constraints;
strategic boundaries;
current stage;
economic model;
network relationship.

The mandate survives individual stewards unless formally amended.

Stewardship opportunity

An invitation to apply for responsibility over a product or domain.

Stewardship grant

The authoritative record delegating powers to a selected steward.

Stewardship term

The start, review, and end period.

Stewardship budget

Resources the steward may allocate under defined controls.

Decision log

Durable records of material decisions, evidence, alternatives, and expected review points.

Handover package

The context, access, obligations, risks, and pending decisions transferred at the end of a term.

Stewardship scopes

A grant may cover:

whole-product operations;
growth;
customer success;
product roadmap;
integrations;
reliability;
developer ecosystem;
community;
a geographic or market segment;
one campaign or experiment portfolio;
compliance implementation;
finance operations within strict limits.

Whole-product stewardship requires the highest level of review and legal clarity.

Required grant fields

Every grant MUST state:

stewardship_grant_id;
product and legal operator;
steward and accountable principal;
term;
scope;
powers;
prohibited actions;
budget and transaction limits;
approval thresholds;
system and data access;
primary objectives;
guardrail metrics;
reporting cadence;
compensation;
IP and confidentiality terms;
conflict policy;
removal and resignation rules;
emergency suspension authority;
handover requirements;
dispute forum;
governing agreements and jurisdiction.

Powers model

Powers are explicit capabilities, not a generic admin role.

Examples:

propose roadmap changes;
publish opportunities;
approve low-risk experiments;
allocate budget up to a limit;
engage qualified contributors;
accept milestones;
issue refunds within policy;
publish selected metrics;
sign routine vendor agreements below threshold;
request additional owner approval.

The grant must distinguish:

propose;
review;
approve;
execute;
spend;
publish;
delegate;
revoke.

Reserved powers

Certain actions SHOULD remain reserved to the legal owner, board, or authorized officer unless a valid legal instrument says otherwise.

Examples:

issuing equity or debt;
changing entity ownership;
opening or closing bank accounts;
borrowing;
entering regulated financial activity;
material asset sale;
hiring or terminating employees;
changing legal terms or privacy commitments;
accessing raw highly sensitive data;
transferring trademarks or core IP;
dissolving the entity;
binding the company above material thresholds.

The interface must not imply that product-level permissions create corporate authority.

Stewardship lifecycle

1. Need identified

A product lacks capacity, expertise, continuity, or focused ownership.

2. Mandate prepared

The product publishes sufficient context, objectives, economics, constraints, and risks.

3. Candidates qualified

Selection may use prior contributions, references, simulations, paid trials, credentials, and interviews.

4. Grant negotiated

Scope, authority, term, compensation, data access, and legal relationship are agreed.

5. Onboarding

The steward receives:

product history;
customer obligations;
current metrics;
security training;
access inventory;
budget status;
open disputes;
roadmap;
key relationships;
current risks.

6. Operating term

The steward acts, records decisions, reports outcomes, and escalates reserved matters.

7. Review

The owner and declared reviewers assess outcomes and process quality.

8. Renewal, expansion, reduction, or end

Authority changes through a new grant version.

9. Handover

Access is transferred or revoked, pending work is explained, and continuity evidence is completed.

Time-bounded by default

All stewardship grants expire.

Recommended initial terms:

experiment steward: days to weeks;
domain steward: one to three months;
whole-product steward: three to six months with scheduled reviews.

Automatic indefinite renewal is discouraged.

Renewal requires:

current mandate;
performance and guardrail review;
conflict disclosure;
updated compensation;
access review;
legal relationship review where material.

Compensation models

Steward compensation may include:

fixed term fee;
hourly or daily compensation where appropriate;
milestone payments;
performance bonus;
product revenue commission;
profit participation under separate reviewed agreement;
equity under formal legal instruments;
contributor reward pool;
network reputation and access.

The interface MUST distinguish conventional compensation from ownership and investment rights.

Revenue share, profit participation, equity, options, tokens, and transferable rights require separate legal analysis.

Product economics

A stewardship opportunity SHOULD disclose enough information for informed participation:

current revenue range or stage;
available operating budget;
recurring costs;
major liabilities;
customer concentration where shareable;
runway or funding policy;
compensation source;
whether the product is profitable;
whether the steward bears any approved expenses;
expected time commitment.

The product must not market speculative upside as guaranteed compensation.

Decision rights matrix

A stewardship grant SHOULD include a table like:

Domain	Propose	Approve	Execute	Spend limit	Escalation
Product experiments	Steward	Steward within policy	Steward/team	$2,000	Owner above threshold
Pricing	Steward	Owner	Steward after approval	N/A	Owner
Contributor bounties	Steward	Steward	Steward	$1,000 each	Owner above cap
Customer refunds	Steward	Policy engine/steward	Steward	$500	Finance owner
Vendor contracts	Steward	Owner	Authorized signer	$0 without signature authority	Legal owner

The protocol never assumes one universal matrix.

Metrics and guardrails

A steward is evaluated against a portfolio, not one vanity metric.

Possible dimensions:

customer value;
revenue or cost outcome;
retention;
delivery reliability;
safety and security;
support quality;
community trust;
documentation;
contributor health;
operational continuity;
compliance;
learning velocity.

A steward must not be rewarded for improving one metric through hidden harm.

Reporting

The stewardship dashboard SHOULD show:

active mandate;
term and remaining time;
powers and limits;
budget used and committed;
decisions awaiting approval;
opportunities opened;
experiments and outcomes;
incidents and disputes;
customer signals;
guardrail status;
compensation accrued;
handover readiness.

Multiple stewards

A product may have several stewards with non-overlapping or coordinated domains.

The operating model must define:

domain boundaries;
conflict resolution;
shared budget rules;
final decision authority;
cross-domain change review;
incident command;
communication expectations.

A product SHOULD avoid creating an informal hierarchy that is invisible in permissions and agreements.

Steward selection

Selection SHOULD prioritize verified relevant contribution over credentials alone.

Signals may include:

accepted contributions;
comparable outcomes;
reviewer quality;
reliability;
conflict history;
domain credentials;
simulation or paid-trial results;
communication and handover quality.

Selection algorithms provide recommendations, not automatic entitlement.

Steward removal

A grant may end because of:

term expiry;
voluntary resignation;
mandate completion;
persistent underperformance;
guardrail breach;
security incident;
fraud or misrepresentation;
conflict of interest;
legal or sanctions restriction;
owner strategic change;
product closure.

Emergency suspension may happen immediately where necessary, but final records should distinguish emergency precaution from adjudicated wrongdoing.

Handover standard

A handover package MUST cover:

current state and recent changes;
open opportunities and assignments;
outstanding payments and refunds;
customer commitments;
credentials and access inventory;
secrets rotation status;
budgets and forecasts;
incidents and risks;
key decisions and rationale;
pending approvals;
next recommended actions.

No steward should be able to hold a product hostage through undocumented knowledge or personal credentials.

Employment and agency boundary

Stewardship can resemble employment or agency when the relationship includes control, permanence, integration, exclusivity, economic dependence, or authority to bind the company.

The product MUST NOT rely on the word steward to avoid:

wage and hour law;
payroll and tax duties;
benefits obligations;
agency law;
fiduciary duties;
corporate authorization rules;
state worker tests.

High-control or ongoing arrangements should be routed to an employment, executive, vendor, management-services, or other appropriate legal structure.

Conflicts of interest

Stewards must disclose relevant conflicts, including:

ownership in competitors;
paid vendor relationships;
personal benefit from recommended tools;
control of reviewer accounts;
undisclosed related contributors;
investments affected by decisions;
use of private product data elsewhere.

Material conflicts may require recusal, additional approval, or termination.

AI as steward

An AI agent may act as an operational assistant or limited automated steward only under an accountable principal.

The grant must define:

model and tool environment;
principal;
actions permitted;
spend limits;
data access;
approval gates;
audit logs;
rollback;
incident stop control;
responsibility for outputs.

An AI agent cannot hold legal office, equity, or fiduciary responsibility merely because the product interface calls it a steward.

Public stewardship record

A product may publish:

current steward identity or pseudonym;
term;
mandate summary;
selected powers;
public goals;
verified outcomes;
handover status.

Private operational details remain permissioned.

MVP acceptance criteria

versioned stewardship grant;
capability-based permissions;
term and expiry;
budget controls;
decision log;
owner approval gates;
compensation terms;
conflict disclosure;
emergency suspension;
access revocation;
handover checklist;
explicit no-ownership and no-automatic-employment language;
legal escalation for whole-product stewardship.

Sources

Verification record

Sources opened and checked: 2 August 2026
Protocol status: Founding draft
Corporate authority review required: Yes
Worker-classification review required: Yes
Securities review for upside compensation: Required before use