Presence Growth Loop

Draft 0.1 — 2 August 2026
Growth mechanisms in this document must remain subordinate to consent, accuracy, utility, and platform policy.

Thesis

ANUKA can grow through a reciprocal presence loop:

• websites introduce visitors to ANUKA;
• the browser extension introduces websites to ANUKA;
• resident companies create useful opportunities;
• participants create verified contributions;
• verified outcomes create public stories and trust;
• trust attracts more companies, participants, and capital.

The goal is not maximum impressions. The goal is maximum useful, permissioned contact between people who can improve products and products ready to be improved.

The two acquisition engines

Site-to-network engine

Company installs ANUKA
        ↓
Visitor opens Backstage
        ↓
Visitor votes, follows, gives feedback, or funds a feature
        ↓
Visitor creates or connects an ANUKA identity
        ↓
Visitor installs the extension or joins the network
        ↓
Participant discovers other resident products

Network-to-site engine

Participant installs the extension
        ↓
Participant opens ANUKA on a website
        ↓
ANUKA shows an official or clearly unclaimed profile
        ↓
Participant submits a suggestion, follow, or claim invitation
        ↓
Company representative claims the profile
        ↓
Company installs the site adapter
        ↓
The website becomes a distribution surface for ANUKA

These engines share one project identity and one presence state.

Value before signup

Every surface should provide immediate value before demanding account creation.

Examples:

• show whether the profile is official;
• display public roadmap and recent improvements;
• allow a local private note;
• explain available opportunities;
• preview the Backstage experience;
• show a company’s selected public quality evidence;
• provide installation diagnostics to an owner.

Authentication should occur when identity is necessary for voting integrity, publication, payment, contribution history, or restricted access.

The presence ladder

A company should progress through visible stages:

Observed
→ Claimed
→ Connected
→ Resident
→ Contextually Verified
→ Actively Improving

Each stage must provide a real benefit and a clear next action.

Observed → Claimed

Value:

• correct public information;
• respond to community feedback;
• control official links;
• distinguish the company from impersonators.

Claimed → Connected

Value:

• official site widget;
• first-party feedback;
• Backstage;
• site analytics and conversion measurement;
• direct communication with participants.

Connected → Resident

Value:

• shared identity and contribution infrastructure;
• bounties and qualified contributors;
• portable evidence;
• network distribution;
• product-stewardship tools.

Resident → Verified

Value:

• specific claims supported by named sources and methods;
• investor, partner, and customer trust;
• eligibility for filtered network catalogs;
• stronger matching to contributors and opportunities.

Verified → Actively Improving

Value:

• continuous feedback-to-experiment loop;
• funded features;
• visible outcomes;
• repeat contributors;
• measurable product quality and growth.

Viral surfaces

Powered by ANUKA

A compact link or badge can create discovery, but it must not become visual spam.

Rules:

• the owner chooses placement within supported configurations;
• the label must open useful context, not a generic advertisement;
• removal terms must be explicit by plan or license;
• the badge must not imply certification unless certification occurred;
• accessibility and performance are mandatory;
• websites must not be forced into deceptive endorsements.

Shareable improvement story

A completed loop can generate an owner-approved story:

Users requested X
→ 148 people supported it
→ 37 participants funded or tested it
→ the company shipped version Y
→ the declared metric changed by Z under method M
→ contributors received recognition or reward

Every story must distinguish correlation, experiment result, and causal claim.

Public contribution proof

A contributor may share a selected record such as:

• accepted feature hypothesis;
• completed test cycle;
• merged implementation;
• verified improvement;
• stewardship milestone;
• public recommendation from a product.

The contributor controls which permitted evidence appears in their public passport.

Company Backstage link

Each connected product receives a stable Backstage URL usable in:

• website navigation;
• social profiles;
• product launch pages;
• support replies;
• changelogs;
• investor updates;
• job and bounty listings;
• QR codes and events.

Extension presence indicator

The extension may show a badge when official ANUKA presence is detected without reading unnecessary page content. Chrome’s declarative content APIs may help activate an extension action based on URL or page conditions with reduced access, but exact cross-browser behavior requires testing.

Content flywheel

ANUKA can produce continuous content from real product activity:

1. a signal is submitted;
2. the company acknowledges it;
3. support accumulates;
4. an opportunity or experiment opens;
5. contributors participate;
6. the result is reviewed;
7. an evidence record is published;
8. an approved story is distributed;
9. participants and the company cross-share it;
10. new participants enter through the story.

The content engine must publish meaningful changes, not manufacture activity.

Distribution rights

Before ANUKA republishes company or participant content, the system must know:

• who owns or controls the content;
• whether publication was authorized;
• approved channels;
• attribution preference;
• whether edits or summaries are permitted;
• embargo or timing rules;
• revocation or correction process;
• sponsorship or compensation disclosures.

A public submission is not automatically permission for unlimited promotional reuse.

Referral model

Referrals should reward verified activation, not raw clicks.

Candidate conversion events:

• company claims its profile;
• company verifies domain control;
• site adapter is installed and active;
• first feedback item is resolved;
• first opportunity is funded;
• first verified outcome is published;
• invited participant completes an accepted contribution.

Rewards may include credits, fee reductions, network status, or conventional payments under applicable terms.

Avoid speculative tokens as the default referral mechanism.

Marketplace liquidity loop

More companies
→ more real opportunities
→ more participant earnings and evidence
→ better matching and reputation
→ faster and higher-quality outcomes
→ stronger company results
→ more companies

The network should track liquidity separately by skill, geography, language, compensation, and task type. A large global task count can conceal an empty market for a specific participant.

Quality loop

Growth only compounds when the outcomes are trusted.

More contributions
→ more reviewed evidence
→ better capability profiles
→ better matching
→ safer delegation
→ higher-value work
→ stronger incentives for quality contributions

Low-quality volume that overwhelms reviewers is negative growth.

Owner growth dashboard

A company should see the complete funnel:

• Backstage impressions;
• meaningful opens;
• feedback submissions;
• votes and unique supporters;
• feature sponsorship commitments;
• contributor applications;
• accepted contributions;
• experiment launches;
• verified outcomes;
• participant-to-customer conversion where authorized;
• extension installs attributable to the site;
• claim invitations originating from participants.

Avoid vanity dashboards that hide denominator, consent state, or data completeness.

Network North Star candidates

The primary network metric should measure repeated verified value creation rather than registrations.

Recommended candidate:

Monthly Verified Improvement Loops — distinct product improvement cycles that reached reviewed evidence and a recorded outcome during the month.

Supporting metrics:

• active resident products;
• active contributors with accepted work;
• time from signal to reviewed outcome;
• percentage of opportunities reaching acceptance;
• repeat contributor rate;
• repeat company publication rate;
• total conventional compensation routed;
• verified outcome dispute rate;
• permission and consent complaint rate;
• company claim-to-install conversion;
• site-to-extension and extension-to-site activation.

Anti-growth metrics

Track damage explicitly:

• extension uninstall after permission prompt;
• blocked script rate;
• site performance regression;
• spam feedback rate;
• rejected or disputed verification claims;
• contributor nonpayment;
• company abandonment after installation;
• misleading public story corrections;
• privacy requests and complaints;
• reviewer overload;
• concentration of earnings or visibility;
• unclaimed-profile confusion rate.

A network that grows by increasing these metrics is not healthy.

Initial experiments

Experiment 1 — Backstage badge

Hypothesis: a useful, clearly labeled Backstage entry increases feedback completion without reducing site trust or performance.

Guardrails:

• page performance;
• bounce rate;
• complaint rate;
• accessibility checks.

Experiment 2 — Extension claim invitation

Hypothesis: participants who discover unclaimed profiles can generate qualified owner leads when invitations include concrete value rather than generic outreach.

Guardrails:

• owner spam reports;
• duplicate invitations;
• false representative claims;
• opt-out effectiveness.

Experiment 3 — Improvement story

Hypothesis: a verified, owner-approved improvement story drives higher-quality network activation than generic product promotion.

Guardrails:

• evidence accuracy;
• participant attribution consent;
• claim substantiation;
• correction rate.

Experiment 4 — Sponsored feature

Hypothesis: monetary support better identifies high-intent demand than votes alone.

Guardrails:

• refund rate;
• delivery expectation clarity;
• payment and consumer-law review;
• roadmap distortion;
• concentration by a single sponsor.

Launch sequence

1. connect ANUKA’s own products;
2. prove the full presence and feedback loop internally;
3. recruit a small set of founder-controlled pilot sites;
4. release direct script and GTM installation;
5. release the participant extension with activeTab mode;
6. enable claim invitations with strict anti-spam controls;
7. publish the first verified improvement stories;
8. add sponsored features only after payment, refund, and delivery terms are ready;
9. expand adapters based on observed demand.

Defensibility

The badge and extension can be copied. The defensible network asset is the accumulated graph connecting:

• verified origins;
• participant contributions;
• product opportunities;
• review policies;
• measured outcomes;
• payments and recognition;
• stewardship history;
• corrections and disputes;
• repeated successful relationships.

The protocol should remain open while the trusted network and high-quality services compound.

Sources

• Chrome activeTab
• Chrome declarative content API
• Chrome Web Store minimum functionality
• Google Tag Manager Community Template Gallery
• FTC Advertising Substantiation Policy

Verification record

• Sources opened and checked: 2 August 2026
• Growth model status: Hypothesis set, not historical performance
• Public claims review required: Yes
• Sponsored-feature legal design required before launch: Yes