Quality Economy Protocol

Draft 0.1 — 2 August 2026
This document defines a product and protocol model. It is not an employment agreement, payment-services opinion, securities offering, tax opinion, or guarantee that an intervention will create value.

Objective

ANUKA treats quality as an economic activity.

A participant should be able to discover a bounded problem, improve a real product or business, prove what happened, receive appropriate compensation, and carry the resulting evidence into future opportunities.

A company should be able to expose selected needs, obtain useful work without opening unrestricted system access, measure results, and pay according to declared rules.

The Quality Economy is the shared protocol that connects:

• signals and opportunities;
• contributors and stewards;
• experiments and operational changes;
• evidence and review;
• rewards and payments;
• reputation and future access;
• organizational learning.

Governing idea

Value is not created by activity alone. It is created when a bounded contribution satisfies declared needs without unacceptable harm, and the result can be examined.

The network therefore separates:

1. work performed;
2. work accepted;
3. change released;
4. outcome observed;
5. outcome attributed;
6. payment earned;
7. reputation updated.

None of these events automatically implies the next.

The quality loop

The canonical loop is:

signal → qualification → opportunity → assignment → contribution → review → release → observation → attribution → reward → learning

Signal

An observation suggesting a problem, need, risk, or opportunity.

Examples:

• repeated customer feedback;
• declining conversion;
• a broken workflow;
• a requested integration;
• support backlog;
• security or reliability anomaly;
• promising but untested growth idea.

Qualification

The network determines whether the signal is sufficiently clear, legitimate, safe, and valuable to become an opportunity.

Qualification SHOULD identify:

• affected product and owner;
• evidence that the issue exists;
• expected beneficiary;
• data and access requirements;
• relevant risks;
• whether the task is suitable for open participation;
• proposed reward model;
• legal or policy constraints.

Opportunity

A structured invitation to contribute.

The opportunity states what is needed, not merely what activity is desired.

Assignment

A defined participant, team, or agent receives bounded authority to work under declared conditions.

Contribution

A reviewable unit of work or insight is submitted.

Review

Qualified reviewers determine whether acceptance criteria were met and whether the work can advance.

Release

The contribution is deployed, published, delivered, or otherwise made operational.

Observation

The system measures what happened after release using a declared window and evidence policy.

Attribution

The network evaluates whether and to what degree the observed result can reasonably be connected to the contribution.

Reward

Payment, credential, reputation evidence, access, or another declared benefit is issued.

Learning

The result, limitations, and reusable pattern are recorded so future work improves.

Quality is contextual

ANUKA MUST NOT define one universal quality score.

Quality depends on:

• stakeholder needs;
• product stage;
• risk level;
• cost and time constraints;
• intended market;
• accessibility and safety requirements;
• business objectives;
• external obligations.

A faster checkout can improve conversion while harming fraud rate. A lower support time can reduce service quality. A feature can increase engagement while decreasing trust.

Every opportunity therefore requires:

• a primary objective;
• guardrail conditions;
• prohibited outcomes;
• evidence requirements;
• decision authority.

Economic objects

The Quality Economy uses explicit object types rather than one generic transaction.

Opportunity

A published need that may or may not include payment.

Bounty

A reward contingent on declared completion or result conditions.

Assignment

A confirmed work relationship for a specific scope.

Stewardship grant

A time-bounded delegation of operational authority over a product or domain.

Sponsored feature

A feature or improvement backed by committed customer or community funds.

Experiment budget

Funds allocated to test a hypothesis, including implementation, traffic, tooling, review, and rollback costs.

Reward allocation

A record describing how value is divided among contributors, reviewers, products, and the network.

Evidence package

The material used to support acceptance, attribution, payment, and reputation claims.

Dispute

A formal challenge to a decision, payment, attribution, record, or process.

Reward dimensions

A reward can recognize different kinds of value.

Delivery reward

Paid when defined work is accepted.

Milestone reward

Paid as declared stages are completed.

Outcome reward

Paid when an observed result satisfies a defined measurement rule.

Review reward

Paid for qualified testing, verification, security review, or acceptance work.

Discovery reward

Paid for finding and documenting a valuable problem or opportunity.

Stewardship compensation

Paid for ongoing bounded responsibility, not for claiming permanent ownership.

Network recognition

Portable evidence, capability credentials, endorsements, access tiers, or invitations to higher-value opportunities.

One transaction may combine several reward dimensions, but each must remain separately legible.

Value is multi-party

An improvement can create value for:

• the product owner;
• customers;
• contributors;
• investors;
• reviewers;
• the ANUKA network;
• future products that reuse the learning.

Reward allocation SHOULD state:

• who funded the work;
• who bore implementation risk;
• who supplied the idea;
• who performed the work;
• who reviewed or tested it;
• who owns resulting intellectual property;
• who receives revenue or savings;
• what fee ANUKA retains;
• what happens when the result is neutral or negative.

Attribution is not ownership

A participant can be credited for an improvement without receiving ownership of the product.

Likewise:

• submitting feedback does not automatically create copyright ownership;
• funding a feature does not automatically create equity;
• writing code does not automatically transfer intellectual property;
• serving as steward does not automatically make someone an officer or director;
• receiving revenue share does not automatically avoid securities, tax, or partnership analysis.

The applicable opportunity terms must state the actual legal rights.

Results over surveillance

The network SHOULD prefer evaluation of bounded outputs and outcomes over continuous monitoring of how a person works.

This supports both dignity and a clearer distinction between independent contribution and supervised employment.

However, measuring only outcomes does not automatically make a contributor an independent contractor. Worker status depends on the entire factual relationship under applicable federal, state, and local law.

Participant autonomy

A participant SHOULD be able to:

• choose opportunities voluntarily;
• see terms before applying;
• decline invasive data requests;
• use their own lawful tools and methods where the assignment permits;
• work across multiple products;
• understand acceptance and payment conditions;
• challenge inaccurate records;
• export legitimate contribution evidence;
• exit the network.

Opportunity design MUST NOT use reputation pressure to coerce acceptance.

Company control

A company retains control over:

• which needs become public;
• which data is shared;
• who receives access;
• whether an experiment reaches production;
• budgets and limits;
• acceptance authority;
• public attribution;
• the final decision to adopt or reject a proposal.

The company must not represent a simulation, vote, or community preference as a guaranteed roadmap commitment unless the applicable terms make that commitment binding.

Network responsibilities

ANUKA’s responsibilities may include:

• standardized opportunity records;
• identity and account assurance;
• permissions and access boundaries;
• payment orchestration;
• ledger and audit records;
• evidence and attestation schemas;
• reviewer qualification;
• dispute workflows;
• portable contribution history;
• fraud and abuse controls;
• public documentation and protocol governance.

ANUKA MUST clearly state when it acts as:

• software provider;
• marketplace operator;
• merchant of record;
• payment facilitator through a regulated provider;
• contracting party;
• data processor or independent controller;
• credential issuer;
• attester;
• reviewer;
• neutral infrastructure.

The same answer will not apply to every resident product.

Tokenless by default

The Quality Economy MUST work using conventional contracts, fiat payments, credentials, and attestations without requiring a speculative token.

Blockchain may support:

• timestamped attestations;
• portable credentials;
• public status records;
• contributor-controlled proofs;
• transparent protocol governance.

Blockchain MUST NOT be used to disguise:

• equity;
• debt;
• profit participation;
• stored value;
• investment contracts;
• payment custody;
• regulated marketplace activity.

Tokenizing a right does not remove the legal character of the underlying right.

Quality Economy North Star

The recommended initial North Star is:

Monthly Verified Improvement Loops

A loop counts only when:

1. a legitimate signal became a bounded opportunity;
2. a contribution was accepted;
3. the change reached its declared operational state;
4. evidence was collected;
5. a result or learning conclusion was reviewed;
6. the applicable reward or closure decision was completed.

A loop can conclude that an intervention failed. Valid negative learning is preferable to unverified positive storytelling.

Supporting metrics

• qualified opportunities published;
• opportunity-to-assignment rate;
• assignment-to-acceptance rate;
• median time to first accepted contribution;
• accepted-contribution-to-release rate;
• percentage with defined guardrails;
• percentage with complete evidence packages;
• payout completion time;
• dispute rate and resolution time;
• repeat contributor rate;
• repeat company rate;
• contributor concentration;
• verified value created or risk reduced;
• percentage of negative and neutral results recorded honestly.

Anti-growth metrics

The network must monitor harms that ordinary growth dashboards hide.

• unpaid speculative work volume;
• opportunities canceled after substantial contributor effort;
• payment delays;
• duplicate or manipulated bounties;
• contribution disputes;
• reviewer conflict-of-interest rate;
• worker-classification risk;
• chargeback and refund rate;
• concentration of rewards among insiders;
• false or misleading verified claims;
• privacy incidents;
• sanctions or tax-reporting failures;
• contributor dependency on one product;
• use of reputation to pressure participation.

MVP boundary

The first Quality Economy release SHOULD support:

• fixed-price bounties;
• milestone assignments;
• paid testing and qualification;
• sponsored features with explicit non-investment terms;
• Stripe Connect payouts;
• platform fees;
• a double-entry internal ledger;
• acceptance evidence;
• refunds and disputes;
• portable contribution records;
• one reviewer or declared reviewer panel;
• manual legal and risk escalation.

The MVP SHOULD NOT support without separate review:

• transferable tokens;
• equity or tokenized equity;
• debt;
• profit participation;
• broad revenue-sharing marketplaces;
• anonymous high-value payouts;
• platform-managed cash wallets;
• use of the word escrow without a compliant provider and legal basis;
• indefinite stewardship;
• automatic worker classification;
• algorithmic firing or employment eligibility decisions.

Acceptance criteria

The protocol is ready for implementation only when:

• every opportunity has a typed reward model;
• acceptance, release, outcome, and payment are separate events;
• guardrails and prohibited results are represented;
• contributors see all material terms before assignment;
• companies cannot silently change acceptance criteria after work begins;
• payments map to a reconciled ledger;
• disputes preserve evidence and deadlines;
• public claims state exactly what was verified;
• high-risk arrangements trigger manual review;
• exit and data portability remain possible.

Sources

• Stripe Connect — Build a marketplace
• Stripe Connect — Collect application fees
• IRS — Independent contractor or employee
• U.S. Department of Labor — Independent contractor rulemaking
• SEC — Statement on Tokenized Securities
• FTC — Advertising substantiation policy

Verification record

• Sources opened and checked: 2 August 2026
• Protocol status: Founding draft
• U.S. legal review required before marketplace launch: Yes
• Payments architecture review required: Yes
• Worker-classification review required: Yes