Small blocks.
Big possibilities.

Start stage design · Roles: owner, platform

Purpose

Reveal the skills and resources members have chosen to share. Move from a name list to an actionable inventory.

What someone can do

Select a capability, inspect consented profiles, then ask whether a specific contribution is available.

Proposed mechanics

Normalize visible skill tags; deduplicate people within each category; group by capability; open only profiles whose visibility permits discovery.

What to measure

Count distinct visible members by skill. A member may appear in multiple categories; category totals are not unique people.

Boundary to preserve

A declared skill is not an offer. Separate self-declared experience from checked credentials. Do not rank human worth.

When there is no data

Show what is known and invite missing context; never interpret missing profiles as missing talent.

Suggested data fields

person_id, community_id, skill_tag, evidence_type, visibility, updated_at

Design direction

Horizontal capability bars and selectable category nodes. Always show coverage and overlapping membership.

Related modules

P05, P08

Start stage design · Roles: owner, platform

Purpose

See what people need alongside what members can actually provide during the same period.

What someone can do

Open an oversubscribed category and recruit providers, create a group session, or review eligible candidates.

Proposed mechanics

Load current needs and offers; align category, unit and time window; exclude expired or unavailable capacity; display both sides on a common scale before testing pair eligibility.

What to measure

Offers and needs are separate counts. Compare available slots and open requests only for compatible units and time windows. A needs-clearance rate is fulfilled needs / eligible needs in one defined cohort; the sample 12 fulfilled out of 20 eligible needs is 60%, not 8 offers / 12 requests.

Boundary to preserve

Do not subtract people from hours or assume all slots fit all requests. Capacity must be reserved to avoid double booking.

When there is no data

No current offers: show an honest gap and an invitation to contribute.

Suggested data fields

need_id, offer_id, category, capacity_remaining, unit, available_from, expires_at, unresolved_need_duration_days, cohort_id, fulfilled_at

Design direction

Paired bars with explicit units, a request-age column and a separate candidate count. Never use a stacked total to imply clearance.

Related modules

P05, P08

Start stage design · Roles: owner, platform

Purpose

Surface useful connections with a clear reason to act, then ask both people for permission.

What someone can do

Review the fit, preview an invitation, request permission, and introduce only after both accept.

Proposed mechanics

Apply scope, expiry, category, timing, capacity and blocking checks; explain the surviving fit; hold capacity; request both permissions; release permitted contact only after both accept.

What to measure

Eligible candidate pairs after permission, timing, location, capacity, and category checks. Distinct needs with candidates is a separate count.

Boundary to preserve

Never display a fabricated compatibility percentage. Re-check capacity and consent before sending.

When there is no data

No eligible candidate: say why, let the member refine their request, or ask for partner-community permission.

Suggested data fields

need_id, offer_id, eligibility_checks, match_reasons, permission_state, capacity_hold

Design direction

Two equal person cards, reasons to connect, invitation preview and a permission status stepper.

Related modules

C02, P08

Start stage design · Roles: owner

Purpose

Help members who explicitly request job or career support without labeling people from inferred employment status.

What someone can do

Triage a private request, identify a résumé reviewer or mentor, and follow up on the agreed action.

Proposed mechanics

Accept an explicitly requested private support case; assign an authorized steward; record the agreed support action; confirm assistance and close with a reason.

What to measure

Open opted-in career requests, age of request, and confirmed assistance. Job placement is counted only when reported and confirmed.

Boundary to preserve

Employment difficulties are member-declared. Sensitive case details stay with authorized stewards, not the public roster.

When there is no data

Offer a discreet way to ask for help and explain who can see the request.

Suggested data fields

request_id, support_type, member_visibility, deadline, assigned_steward, case_status

Design direction

Private case queue with age, owner and next action. Keep sensitive narrative out of the community map.

Related modules

P08, P10

Start stage design · Roles: owner, platform

Purpose

See where introductions stall and make sure a promising connection becomes useful help.

What someone can do

Review waiting cases, send an appropriate reminder, or close a request with a reason.

Proposed mechanics

Build one introduction cohort; derive state from recorded events; show cases still awaiting a response or outcome; offer a consent-aware follow-up action.

What to measure

Track one cohort from proposal to acceptance to outcome. Pending and declined cases stay distinct.

Boundary to preserve

No automatic repeated nudges. Respect withdrawal, do-not-contact preferences, and blocked relationships.

When there is no data

No introductions yet: create one from a real current need.

Suggested data fields

introduction_id, proposed_at, accepted_by_each, introduced_at, outcome_id, closed_reason

Design direction

Stage funnel and actionable queue. Show pending and declined cases separately rather than hiding them.

Related modules

C03, C06

Start stage design · Roles: owner, platform

Purpose

Capture a small, credible record of what happened and whether the recipient found it useful.

What someone can do

Ask both parties a short follow-up, resolve conflicting answers, and add a consented story to the impact report.

Proposed mechanics

Ask provider and recipient about the specific help; keep independent responses; resolve conflicting reports; attach evidence level and an outcome type.

What to measure

Unique fulfilled needs and unique beneficiaries per period. Distinguish self-reported, jointly confirmed, and transaction-backed evidence.

Boundary to preserve

An accepted introduction is not a job, venture, or completed service. Keep money, hours, and outcomes in separate units.

When there is no data

Pending evidence is shown as pending, never silently converted into failure or success.

Suggested data fields

outcome_id, need_id, outcome_type, confirmed_by, confirmed_at, usefulness, evidence_source

Design direction

Compact outcome receipt with confirmation sources, date, usefulness and a correction path.

Related modules

C03, P08

Grow stage design · Roles: owner, platform

Purpose

Turn repeated needs into shared interventions such as office hours, workshops, or a mentor circle.

What someone can do

Review a cluster, ask members whether a group format helps, and draft a program with an available facilitator.

Proposed mechanics

Group compatible current needs; compare available facilitators and time windows; ask members if a group format fits; publish only after a facilitator accepts.

What to measure

Count compatible requests within a defined time window; validate interest before committing resources.

Boundary to preserve

Category similarity alone does not imply shared circumstances or permission to disclose individual needs.

When there is no data

Too few compatible requests: keep individual routing or collect explicit interest.

Suggested data fields

need_category, open_request_count, preferred_times, provider_capacity, program_interest

Design direction

Opportunity card beside a cluster of needs. Include the assumption and the smallest next organizing step.

Related modules

C02, C18

Start stage design · Roles: owner

Purpose

Match willing people to specific roles, times, and commitments.

What someone can do

Inspect a role, invite eligible volunteers, confirm a shift, and record completion.

Proposed mechanics

Create a role with eligibility and shift capacity; invite opted-in people; record acceptance; hold slots; confirm attendance and actual hours separately.

What to measure

Unfilled role slots, confirmed commitments, and completed volunteer hours recorded separately.

Boundary to preserve

A volunteering skill tag is not consent to be scheduled. Eligibility requirements depend on the role.

When there is no data

Show open roles and an opt-in offer flow; do not imply everyone is available.

Suggested data fields

role_id, required_skills, shift_time, capacity, volunteer_opt_in, attendance_confirmation

Design direction

Shift board with open, held and confirmed places; a clear distinction between willingness and assignment.

Related modules

C02, P08

Grow stage design · Roles: owner

Purpose

Make member businesses discoverable and route relevant service requests with clear commercial terms.

What someone can do

Compare relevant offers, request an introduction, and disclose any referral fee before acceptance.

Proposed mechanics

Index permitted service listings; filter by service area, current availability and request fit; disclose terms; route the request; record completed work and transactions separately.

What to measure

Track service requests, accepted referrals, confirmed work, and recorded transaction value separately.

Boundary to preserve

Community membership does not certify quality or professional licensing. Sponsored listings are clearly labeled.

When there is no data

No matching provider: retain the request and offer a permissioned referral outside the community.

Suggested data fields

business_id, service_tags, service_area, availability, pricing_mode, referral_id, transaction_id

Design direction

Service cards plus a referral and transaction ledger. Place any sponsored label beside the offer.

Related modules

C03, P11

Start stage design · Roles: owner, platform, ambassador

Purpose

Learn which QR codes, events, and invitation links create meaningful participation.

What someone can do

Compare invite channels, inspect drop-off, and improve the onboarding step with the largest loss.

Proposed mechanics

Attribute joins to an entry point under a declared window; deduplicate scans; follow the same join cohort through current context and first outcome; calculate time to each milestone.

What to measure

Compare the same attributed join cohort by profiles created, current-context completion, first confirmed outcome and median time to current context. Filter repeat and bot scans. A 48/80 current-context cohort is 60% complete; this does not score the quality of people.

Boundary to preserve

Do not equate scans with people or attendance. Filter obvious bots and deduplicate repeated activity.

When there is no data

No attributed events: explain instrumentation and show an empty funnel.

Suggested data fields

entry_point_id, entry_point_type, scans_total, attributed_join_id, profiles_created, current_context_at, profile_completion_percentage, first_outcome_at, attribution_window

Design direction

Entry-point comparison table and cohort funnel. Profile completion describes information coverage, not human value.

Related modules

C11, P03

Start stage design · Roles: owner, ambassador

Purpose

Help new members reach their first useful interaction, beyond profile completion.

What someone can do

Identify the next incomplete step, offer relevant guidance, and hand off people who need support.

Proposed mechanics

Define a join cohort and observation window; derive context, introduction and first-outcome milestones; identify the missing step and offer relevant support.

What to measure

Cohort-based activation: first confirmed useful outcome within a defined period. Show the period and incomplete observation windows.

Boundary to preserve

Ambassadors see aggregate activation for their accounts, not members’ private needs or conversations.

When there is no data

Recent cohorts remain in progress until the observation window ends.

Suggested data fields

membership_id, joined_at, context_created_at, introduction_id, first_outcome_at

Design direction

Milestone funnel with incomplete observation windows marked in progress.

Related modules

C03, C06

Start stage design · Roles: owner, platform

Purpose

Keep a portable profile with community-specific membership and visibility. Preserve the original identity and contact-sharing idea.

What someone can do

Choose visible fields, share a link or QR code, and manage community membership and contact permissions.

Proposed mechanics

Store identity separately from community memberships; enforce field visibility per membership; show independent verification claims; render a shareable profile and export.

What to measure

Profile readiness is a utility checklist, not a score of member value. Verify each claim independently.

Boundary to preserve

Membership confirmation, identity proofing, and credential checks have separate labels and expiry. Avoid “owned forever” claims without a delivery policy.

When there is no data

Allow a minimal profile and progressive completion.

Suggested data fields

person_id, profile_fields, membership_id, field_visibility, verification_claim, share_link

Design direction

Member profile with visibility controls, share link, memberships and claim-specific verification labels.

Related modules

P04, P08, P09

Start stage design · Roles: owner

Purpose

Retain useful profile links, booking pages, and deliberate contact exchange without crowding the command center.

What someone can do

Open a booking link, share a contact card, or exchange details through an explicit action.

Proposed mechanics

Save member-selected destinations and explicit exchange permission; validate link types; record deliberate contact exchanges; let members revoke sharing.

What to measure

Track consented exchanges as relationships. A profile visit is not a named connection.

Boundary to preserve

Do not identify anonymous viewers or silently import someone’s address book into a community directory.

When there is no data

A profile with no links still works for needs, offers, and introductions.

Suggested data fields

profile_id, link_type, destination, contact_exchange_consent, relationship_id

Design direction

Simple contact actions and useful links, separate from operational dashboard metrics.

Related modules

C12, P09

Grow stage design · Roles: owner, platform

Purpose

Show how money was allocated, what is pending, and what the community actually received.

What someone can do

Inspect the calculation and policy version, review adjustments, and export an approved statement.

Proposed mechanics

Read approved allocations and settlement records; apply refunds and adjustments; reconcile accrued = paid + pending; expose the policy and period.

What to measure

Accrued amount = paid amount + pending amount after adjustments. Keep platform revenue and community share distinct.

Boundary to preserve

Illustrative policy until agreed. Revenue sharing does not automatically establish ownership or cooperative governance.

When there is no data

No earnings yet: show zero and explain eligible activity without projecting guaranteed returns.

Suggested data fields

allocation_id, policy_version, period, accrual, refund_adjustments, settlement_id

Design direction

Readable statement with calculation drill-down and clearly separated paid and pending amounts.

Related modules

P11, P18

Scale stage design · Roles: owner, platform

Purpose

Find complementary help in another community when local capacity is insufficient.

What someone can do

Ask for broader discovery, share only the approved request, and introduce through a partner steward.

Proposed mechanics

Check the partner agreement and member-approved scope; search eligible partner offers; request a bounded introduction; attribute confirmed results without duplicating them.

What to measure

Cross-community requests, accepted introductions, and confirmed outcomes; deduplicate people with multiple memberships.

Boundary to preserve

Never expose all profiles across communities by default. Authorization is checked on each route and field.

When there is no data

No partner capacity: preserve the request and invite a new partner deliberately.

Suggested data fields

source_community, target_community, request_scope, sharing_consent, partner_agreement, route_id

Design direction

Community bridge diagram with scope, permission and status alongside the route.

Related modules

C03, P15

Grow stage design · Roles: owner, platform

Purpose

Understand whether relevant invitations reach members and whether participation is broadening.

What someone can do

Choose an opted-in audience, preview an invitation, and compare participation across cohorts.

Proposed mechanics

Select a permitted audience for a relevant invitation; log delivery, response and participation; compare equivalent cohorts and outcomes.

What to measure

Delivery, response, participation, and outcomes with explicit denominators. Segment only on permitted, relevant attributes.

Boundary to preserve

Clicks are useful operational signals, not proof of social impact. Avoid sensitive inferred segmentation.

When there is no data

No response data: show unknown rather than assuming members are disengaged.

Suggested data fields

campaign_id, recipient_consent, delivered_at, responded_at, participation_event, cohort

Design direction

A reach funnel with denominators and an outcome panel. Avoid a single engagement score.

Related modules

P08, C06

Start stage design · Roles: platform

Purpose

See the platform’s communities, data coverage, and current operating activity in one place.

What someone can do

Drill into a community’s health signals and assigned operator, then prioritize support.

Proposed mechanics

Aggregate unique people separately from memberships; group by community and period; calculate coverage and activity using shared definitions; drill into authorized operations.

What to measure

Separate unique people, memberships, active communities, and current contributors. Aggregate without double counting.

Boundary to preserve

Platform-level oversight does not grant blanket access to sensitive member content.

When there is no data

New communities show onboarding progress and coverage, not invented activity.

Suggested data fields

community_id, membership_id, person_id, current_context, period, community_status

Design direction

Network summary, distribution chart and exception queue. Put actionable gaps beside counts.

Related modules

P03, P08

Start stage design · Roles: platform

Purpose

Find stale offers, missing constraints, invalid tags, and duplicated records before they damage recommendations.

What someone can do

Inspect a flagged record, ask for clarification, correct source data, and rerun validation.

Proposed mechanics

Run versioned completeness, validity, freshness and duplication rules; create review tasks with source evidence; revalidate after correction.

What to measure

Issue counts by type and severity; freshness is measured against category-specific expiry policies.

Boundary to preserve

Preserve the original and a correction history. Do not silently rewrite a member’s intent.

When there is no data

No issues found means checks passed, not that all underlying claims are true.

Suggested data fields

entity_id, validation_rule, source, updated_at, quality_issue, resolution

Design direction

Issue queue organized by severity and owner, with before-and-after source comparison.

Related modules

P03, P05

Start stage design · Roles: platform

Purpose

Bring existing rosters into a clean, reviewable onboarding process.

What someone can do

Map source fields, preview changes, review rejected rows, then invite members to claim and confirm.

Proposed mechanics

Map an import to approved fields; preview validation and duplicate candidates; preserve source lineage; invite people to claim records; reconcile accepted and rejected rows.

What to measure

Rows received, valid rows, review-required rows, and member-claimed profiles. Imported records are not automatically active members.

Boundary to preserve

Imports do not create consent for discovery or outreach. Minimize collected fields and avoid overwriting verified facts.

When there is no data

Show a sample field map before any real import.

Suggested data fields

import_batch_id, source_row_id, mapping_version, consent_basis, validation_status, member_claim_status

Design direction

Import funnel, field mapper and rejected-row explanation. Imported does not mean consented.

Related modules

P04, P08

Start stage design · Roles: platform

Purpose

Connect multiple community memberships to the right person without accidental merging.

What someone can do

Compare permitted evidence, ask for member confirmation, merge carefully, and retain a reversible history.

Proposed mechanics

Generate possible duplicate candidates from permitted evidence; compare records; require suitable confirmation; preserve reversible merge history.

What to measure

Suspected duplicates are review tasks, not automatic identity determinations.

Boundary to preserve

Shared names, households, and devices are not sufficient proof. Never merge identities on similarity alone.

When there is no data

Uncertain records remain separate.

Suggested data fields

person_id, membership_id, verified_contact, duplicate_signal, merge_review, reversal_record

Design direction

Side-by-side profile review with explicit uncertainty and a reversible merge decision.

Related modules

P08, P09

Start stage design · Roles: platform

Purpose

Keep skills, needs, offers, and goals understandable across communities while allowing local vocabulary.

What someone can do

Suggest a normalized category, let the member confirm it, and maintain aliases with version history.

Proposed mechanics

Map member language to versioned skill and intent categories; retain original wording; suggest aliases; ask for confirmation when meaning is ambiguous.

What to measure

Unmapped terms, confirmed mappings, and tag changes that affect eligibility.

Boundary to preserve

AI suggestions remain suggestions. Preserve original wording and do not infer sensitive attributes.

When there is no data

Unclassified text remains usable and can enter manual review.

Suggested data fields

canonical_tag, alias, locale, category_version, member_confirmation, source_text

Design direction

Tag mapping workbench with original phrase, proposed term, evidence and review status.

Related modules

P03, P08

Grow stage design · Roles: platform

Purpose

Monitor the operational path from eligible candidate to actual help.

What someone can do

Inspect drop-off and failure reasons, then repair rules or delivery issues.

Proposed mechanics

Join eligibility, delivery, acceptance and outcome events using route IDs; follow a defined cohort; group blocked or failed routes by reason.

What to measure

One cohort’s eligible, proposed, accepted, and completed routes. Separate technical failures from human declines.

Boundary to preserve

A ranking change must not bypass consent, blocked pairs, or capacity checks.

When there is no data

No routing history: use deterministic rules and a human review queue.

Suggested data fields

route_id, rule_version, eligibility_result, delivery_status, acceptance_event, outcome_event

Design direction

Stage funnel and reason breakdown. Human decline must remain distinct from delivery failure.

Related modules

C03, C06, P14

Grow stage design · Roles: platform

Purpose

Learn which recommendations are useful and whether exposure is concentrated unfairly.

What someone can do

Review a sample of matches, test changes against a baseline, and roll back degraded behavior.

Proposed mechanics

Sample recommendations for review; compare model versions against a simple baseline; measure relevance, acceptance, usefulness and exposure; roll back degraded versions.

What to measure

Precision on reviewed candidates, acceptance, outcome usefulness, and exposure distribution. Compare like-for-like cohorts.

Boundary to preserve

Historical selection is biased. Do not optimize only for popular members or use protected-trait proxies.

When there is no data

Insufficient evidence: retain simple rules and report uncertainty.

Suggested data fields

model_or_rule_version, shown_candidate, review_label, decline_reason, outcome, exposure_count

Design direction

Version comparison with sample sizes and outcome evidence, plus an exposure-distribution panel.

Related modules

P06, P08

Start stage design · Roles: platform

Purpose

Make access decisions and changes to sensitive records inspectable.

What someone can do

Inspect an access event, review role grants, and revoke unnecessary access.

Proposed mechanics

Resolve actor, role, tenant, purpose and field scope for each request; record the decision; support scoped grants and revocation; inspect audit trails.

What to measure

Allowed and denied access by policy version; high-risk permission changes are reviewable events.

Boundary to preserve

Least privilege and community boundaries apply server-side. Demo role switching is not production authorization.

When there is no data

No audit events: confirm instrumentation before displaying a security assurance.

Suggested data fields

actor_id, role, scope, permission, resource_id, decision, audit_timestamp

Design direction

Permission matrix and audit timeline. A dashboard dropdown only previews a role.

Related modules

P04

Start stage design · Roles: platform

Purpose

Operationalize visibility, consent changes, retention, export, and deletion.

What someone can do

Process an access/export/deletion request and propagate visibility changes to search and routing.

Proposed mechanics

Apply consent and retention rules to records, indexes, exports and backups under defined policies; propagate changes; verify deletion or export completion.

What to measure

Open requests, overdue actions, and completed lifecycle operations with evidence.

Boundary to preserve

Aggregates can still reveal people in small groups. Suppress small cells and prevent revealing differences across filters.

When there is no data

No requests pending is not evidence of full compliance; show the process state only.

Suggested data fields

consent_record, purpose, visibility, retention_policy, deletion_request, completion_record

Design direction

Lifecycle queue with requested, processing and completed states plus evidence.

Related modules

P08

Start stage design · Roles: platform

Purpose

Handle reports, unwanted introductions, suspicious offers, and disputes through human review.

What someone can do

Triage, restrict risky activity when justified, review evidence, and communicate an appeal route.

Proposed mechanics

Receive a report; triage severity; assign authorized reviewers; preserve evidence; record decisions and appeals; communicate only the permitted result.

What to measure

Open reports by severity and age, response time, and appeal outcomes.

Boundary to preserve

Avoid global social scores or public allegations. Share case details only with authorized reviewers.

When there is no data

No open cases: show reporting pathways and recent operational checks.

Suggested data fields

report_id, reporter, reason, resource, review_status, appeal, resolution

Design direction

Private support queue with status, owner, deadline and appeal path.

Related modules

P08, P09

Grow stage design · Roles: platform

Purpose

Separate platform income, costs, distributable funds, community allocations, and settled transfers.

What someone can do

Review the pool calculation, apply an approved allocation policy, and reconcile each payout.

Proposed mechanics

Reconcile transactions, fees, refunds and costs; compute defined distributable profit; apply the approved pool and allocation policy; post settlements and reversals.

What to measure

Reconcile each layer independently. A sample 50% share of $4,800 defined distributable profit yields a $2,400 pool.

Boundary to preserve

Define the profit basis before promising percentages. No allocation from clicks or an opaque vitality score.

When there is no data

No approved policy: keep calculations in a labeled scenario, not a payable balance.

Suggested data fields

transaction_id, refund_id, cost_category, pool_period, policy_version, allocation_id, settlement_id

Design direction

Financial ledger with separate revenue, profit, allocated, paid and pending layers.

Related modules

P18, P08

Grow stage design · Roles: platform, owner

Purpose

Prove whether a sponsored program reached an opted-in audience and delivered its promised benefit.

What someone can do

Review audience fit, approve labeled sponsor content, and report aggregate program outcomes.

Proposed mechanics

Define explicit audience eligibility; review context fit; invite opted-in members with sponsorship disclosed; log participation and confirmed benefit; audit a relevance sample.

What to measure

Alignment relevance = relevant reviewed deliveries / reviewed deliveries, with sample method and size. A sample 36/40 is 90% reviewed relevance, not universal accuracy. Report eligible → invited → opted in → participated → confirmed benefit separately; cost per outcome needs actual recorded cost.

Boundary to preserve

Sponsorship does not buy access to private member needs or covert ranking priority.

When there is no data

No outcome evidence: report participation only.

Suggested data fields

campaign_id, eligibility, explicit_context, opt_in, invitation, participation, outcome, disclosure, reviewed_delivery_count, relevant_reviewed_count, program_cost

Design direction

Sponsor alignment funnel plus reviewed relevance rate and cost per confirmed outcome.

Related modules

P07, P17

Grow stage design · Roles: platform, owner

Purpose

Translate verified activity into a clear, permissioned account of community benefit.

What someone can do

Choose a reporting period, inspect evidence, and approve an aggregate report or consented story.

Proposed mechanics

Assemble eligible confirmed outcomes and settled returns; deduplicate beneficiaries; suppress unsafe small groups; approve claims, stories and reporting methodology.

What to measure

Publish confirmed outcomes, unique beneficiaries, and paid community return as separate measures.

Boundary to preserve

Do not turn collaborator matches into “ventures founded,” volunteer signups into hours served, or sample values into real impact.

When there is no data

Low counts: combine periods or withhold details to protect identities.

Suggested data fields

outcome_type, period, confirmation_level, unique_beneficiary, paid_return, publication_consent

Design direction

Public report preview with category cards, circulation chart and evidence links.

Related modules

P19, P20, P21

Grow stage design · Roles: platform

Purpose

Keep invitations, searches, and background jobs dependable as the network grows.

What someone can do

Retry recoverable failures with idempotency, investigate repeated errors, and communicate relevant incidents.

Proposed mechanics

Instrument each delivery attempt and job; record queue age, retry reason and idempotency key; retry only eligible operations; surface incidents.

What to measure

Successful deliveries / attempted deliveries, queue age, latency percentiles, and actionable failures.

Boundary to preserve

Delivery success is not human response. Never retry a revoked or expired invitation.

When there is no data

Missing telemetry is shown as unavailable, not 100% uptime.

Suggested data fields

job_id, queue_age, delivery_attempt, failure_code, latency, incident_id

Design direction

Operational status chart and failed-job queue with retry eligibility explained.

Related modules

P08

Scale stage design · Roles: platform

Purpose

Coordinate partner communities without creating unrestricted global access to people.

What someone can do

Identify complementary capacity, review an agreement, and open a bounded discovery bridge.

Proposed mechanics

Register partner agreements and source restrictions; enforce scope on each cross-community query; log route lineage and policy; reconcile shared outcomes.

What to measure

Accepted inter-community routes, completed outcomes, and attributed benefits under a declared deduplication rule.

Boundary to preserve

Keep local stewardship and member permission. Cross-network search must honor the source community’s restrictions.

When there is no data

No approved bridge: show a partnership request rather than member records.

Suggested data fields

community_pair, agreement, request_scope, consent, route_id, attribution_rule

Design direction

Partner network with direction, agreement scope and route status; no unrestricted member search.

Related modules

C15, P08

Start stage design · Roles: ambassador

Purpose

Keep a deliberate record of organizers, institutions, and businesses interested in the platform.

What someone can do

Capture a prospect with permission, add context, and schedule the next agreed conversation.

Proposed mechanics

Capture a consented organization contact; deduplicate against assigned accounts; record needs, stage and next agreed action; assign ownership.

What to measure

Unique qualified organizations with a defined next action. Deduplicate across ambassadors.

Boundary to preserve

No scraping of private member lists. Prospect contacts are not enrolled community members.

When there is no data

Start with a real conversation and a clear reason for follow-up.

Suggested data fields

prospect_id, organization, consented_contact, source, owner, next_action, stage

Design direction

Relationship list with next action and owner. Do not import private member rosters.

Related modules

P04, P08

Start stage design · Roles: ambassador, platform

Purpose

Move communities from a first conversation to an activated pilot with clear stage definitions.

What someone can do

Inspect the stalled stage, identify the next agreed action, and record why a prospect progressed or declined.

Proposed mechanics

Define prospect cohort and stage events; retain lost or declined outcomes; compute transitions only within that cohort; surface stalled next steps.

What to measure

Track a defined cohort across qualified, demo, pilot, and activated stages; do not divide unrelated stock counts.

Boundary to preserve

A signed pilot is not an active community. Define activation by actual member value.

When there is no data

No pipeline: show a first-prospect action and qualification criteria.

Suggested data fields

prospect_id, qualified_at, demo_at, pilot_agreed_at, activated_at, lost_reason

Design direction

Pipeline columns or funnel with dates and the reason each organization moved.

Related modules

A01, A06

Grow stage design · Roles: ambassador

Purpose

Plan outreach across assigned regions using organization records and confirmed meetings.

What someone can do

Review an assigned region, group nearby meetings, and prepare a relevant demonstration.

Proposed mechanics

Group assigned organization locations and confirmed meetings; verify coordinates if mapping; prevent duplicate ownership; plan visits around agreed appointments.

What to measure

Qualified prospects, booked visits, and activation by region. A location chart uses organization addresses, not member tracking.

Boundary to preserve

Do not infer market size from platform penetration. A future geographic view needs verified coordinates and a real basemap.

When there is no data

Unassigned territory: request ownership before contacting duplicate prospects.

Suggested data fields

organization_id, city, territory, assignment, meeting_time, visit_status

Design direction

Territory bars now, organization map when geocoded, and a next-visit agenda.

Related modules

A01, P08

Start stage design · Roles: ambassador

Purpose

Show what the product could do using explicit assumptions and a clearly labeled sample community.

What someone can do

Choose community type, adjust assumptions, and walk through a sample introduction and outcome.

Proposed mechanics

Take explicit member, participation, need and offer assumptions; show the arithmetic and uncertainty; demonstrate one hypothetical permission flow.

What to measure

Scenario arithmetic only: participants × explicitly chosen rates. No prediction of economic value or guaranteed matches.

Boundary to preserve

Never present scenario output as measured data. A member count alone cannot predict hidden wealth or compatible pairings.

When there is no data

Use a sample with a visible “illustration” label until real consented data exists.

Suggested data fields

scenario_member_count, participation_assumption, request_rate, offer_rate, capacity_assumption

Design direction

Editable scenario sliders with labeled outputs and an unknown actual-match result.

Related modules

C03

Start stage design · Roles: ambassador, platform

Purpose

Connect outreach activity to organization onboarding and real activation.

What someone can do

Create a campaign-specific invite and inspect where interested organizers drop off.

Proposed mechanics

Generate source-specific invitations; connect consented organizations to a declared attribution window; resolve duplicates and shared credit; follow through to activation.

What to measure

Attributed qualified organizations, agreed pilots, and activated communities under one documented rule.

Boundary to preserve

Attribution is not proof of causation. Define duplicate claims, shared credit, and attribution expiry.

When there is no data

Unattributed activity stays unattributed rather than assigned to the latest touch by default.

Suggested data fields

ambassador_id, invite_id, prospect_id, attribution_window, community_id, activation_event

Design direction

Invitation-source funnel and attribution exception list.

Related modules

A01, A02

Start stage design · Roles: ambassador, owner

Purpose

Give every new community a repeatable path from interest to its first useful outcome.

What someone can do

Confirm a steward, choose one use case, seed real supply and demand, and facilitate the first introduction.

Proposed mechanics

Name a steward and a first use case; seed available offers and real requests; facilitate a first introduction; obtain a confirmed useful outcome.

What to measure

Milestones completed and blocked, with an accountable owner and due date.

Boundary to preserve

A complete checklist alone is not a successful pilot. Require member feedback and a confirmed useful outcome.

When there is no data

New pilot: begin with the steward and intended member benefit.

Suggested data fields

community_id, named_steward, scope, member_invites, provider_offers, first_route, first_outcome

Design direction

Launch checklist with owner and evidence for each milestone, not a percentage of promised success.

Related modules

C03, C06

Grow stage design · Roles: ambassador, platform

Purpose

Find pilots that need practical support rather than more selling.

What someone can do

Spot a lack of offers or unanswered requests and arrange a support session with the community steward.

Proposed mechanics

Read only assigned-account aggregates; compare pilot coverage and outcomes in equivalent windows; identify missing supply or demand; assign a support action.

What to measure

Coverage and milestone progress within an assigned account. Compare accounts only with the same observation window.

Boundary to preserve

Ambassadors get aggregate activation and assigned tasks, not access to individual employment problems.

When there is no data

No current context: help the organizer onboard a small cohort instead of generating fake insights.

Suggested data fields

community_id, pilot_start, current_context_count, provider_count, open_needs, first_outcome

Design direction

Pilot comparison cards with the next milestone and no member-level private needs.

Related modules

A06, P08

Start stage design · Roles: ambassador, owner

Purpose

Preserve the commitments made during onboarding and hand the account to the right support owner.

What someone can do

Write the agreed scope, assign the ongoing owner, and schedule a review with the organizer.

Proposed mechanics

Record scope, success criteria and commitments; assign the receiving owner; request handoff acceptance; carry unresolved commitments into scheduled reviews.

What to measure

Open commitments, accepted handoffs, and first-outcome status.

Boundary to preserve

Do not promise unavailable functionality or unapproved payout terms. Keep a visible version of the agreement.

When there is no data

Unaccepted handoff remains assigned to the existing owner.

Suggested data fields

account_id, agreed_scope, success_criteria, owner, next_review, open_commitment

Design direction

Handoff timeline with explicit ownership and outstanding actions.

Related modules

A01, A06

Grow stage design · Roles: ambassador, platform

Purpose

Give ambassadors a transparent statement based on approved commercial terms.

What someone can do

Inspect eligible activity, review an adjustment, and see the settlement status.

Proposed mechanics

Evaluate eligible earning events against contract version; approve commissions; post adjustments and settlements; reconcile pending balances.

What to measure

Separate estimated, approved, and paid commission. Tie each line to a contractual earning event.

Boundary to preserve

Separate commissions from the community pool. No earnings promises before the contract and eligibility rules exist.

When there is no data

No approved contract: show the policy placeholder, not a projected balance.

Suggested data fields

contract_version, eligible_account, commission_event, refund_adjustment, approval, settlement

Design direction

Personal earnings statement with estimated, approved, pending and paid separated.

Related modules

P11, P08

Grow stage design · Roles: ambassador, platform

Purpose

Bring real objections, successful use cases, and consented outcome stories back into product learning.

What someone can do

Capture a field insight, link a verified story, and route a repeated objection to the product team.

Proposed mechanics

Capture field feedback with consent; tag recurring themes; link evidence-backed outcomes; distinguish requests from commitments; route findings to product owners.

What to measure

Count recurring themes across distinct organizations. Stories are evidence of examples, not universal effectiveness.

Boundary to preserve

Do not publish names, photos, or identifiable stories without permission. Separate requested features from promised roadmap.

When there is no data

No proof yet: demonstrate the workflow honestly and collect pilot feedback.

Suggested data fields

interview_id, organization_type, objection_tag, consented_quote, verified_outcome, feature_request

Design direction

Learning board with source context, frequency and consented stories.

Related modules

A01, C06

Grow stage design · Roles: owner

Purpose

Map useful community assets beyond skills: spaces, equipment, training materials, and available services.

What someone can do

Find a suitable asset, request access, and confirm use under the owner’s conditions.

Proposed mechanics

Record asset ownership, capacity and booking conditions; expose permitted listings; reserve against availability; confirm actual use.

What to measure

Available resources by type and time, with reservations and confirmed use tracked separately.

Boundary to preserve

Listing an asset is not granting universal access. Availability, responsibility, and booking terms must be explicit.

When there is no data

Show a contribution invitation rather than assuming the community owns the resource.

Suggested data fields

resource_id, owner, resource_type, availability, capacity, booking_rules, visibility

Design direction

Resource inventory with availability calendar and explicit request-to-book action.

Related modules

C12, P08

Grow stage design · Roles: owner, platform

Purpose

Turn explicitly shared demand into a possible group purchase with clear terms and voluntary participation.

What someone can do

Validate demand, request a vendor quote, share terms, and let members opt in before committing funds.

Proposed mechanics

Collect opt-in purchase interest with units; obtain a quote; disclose terms; distinguish commitments from paid orders; track fulfillment and refunds.

What to measure

Interest, committed quantity, paid orders, and fulfilled orders. Savings require a documented comparison basis.

Boundary to preserve

Interest is not an order. Do not pool money or promise discounts before the process and responsibilities are defined.

When there is no data

Insufficient demand: close the proposal without obligation.

Suggested data fields

purchase_interest, quantity, budget_band, vendor_quote, member_commitment, order, fulfillment

Design direction

Demand-to-order funnel and a terms panel before any commitment.

Related modules

P11, P08

Grow stage design · Roles: owner, ambassador

Purpose

Help an event produce useful follow-up through explicit attendee interests and offers.

What someone can do

Invite attendees to share one intent, suggest relevant introductions, and follow up after the event.

Proposed mechanics

Invite optional event check-ins and current intent; propose eligible introductions; obtain consent; follow up and attribute confirmed help under a stated rule.

What to measure

Opted-in participants, accepted introductions, and confirmed outcomes attributable under a stated rule.

Boundary to preserve

A QR scan does not prove attendance or reveal who is nearby. Never imply precise seat or row location.

When there is no data

No shared intent: offer a short optional prompt instead of generating recommendations.

Suggested data fields

event_id, optional_check_in, need_or_offer, intro_permission, followup, outcome

Design direction

Event funnel and follow-up queue; entry-point scans alone are not attendance.

Related modules

C03, C10

Scale stage design · Roles: owner, platform

Purpose

Explore actual consented relationships, isolated groups, and bridges between circles.

What someone can do

Filter by a relationship type, inspect evidence, and invite a steward to support a disconnected group.

Proposed mechanics

Load visible observed relationships with provenance; keep proposed routes and shared categories as different edge types; filter context groups; inspect only permitted evidence.

What to measure

Show observed relationships separately from suggested matches and shared categories. Coverage limits every interpretation.

Boundary to preserve

No inferred friendship or trust from co-membership. Do not expose private relationships or score a person’s social worth.

When there is no data

Sparse graph: show the coverage limit and use a capability atlas instead.

Suggested data fields

relationship_id, relationship_type, source_evidence, participants, visibility, timestamp

Design direction

Selectable constellation with separate observed, suggested and category layers plus a keyboard-accessible list.

Related modules

C01, P08

Scale stage design · Roles: owner, platform

Purpose

Plan future support using sufficient historical demand, seasonality, and measured service capacity.

What someone can do

Explore a demand scenario, compare available capacity, and decide whether to recruit or schedule a program.

Proposed mechanics

Build category-level history with coverage and service capacity; compare a simple baseline to a forecast; backtest error; display ranges and model version.

What to measure

Forecast ranges evaluated against a simple baseline, with error and sample size. Separate projections from observed data.

Boundary to preserve

No reliable forecast from a small or changing sample. Show uncertainty and avoid sensitive individual predictions.

When there is no data

Insufficient history: show recent observed demand only.

Suggested data fields

category, period, open_requests, fulfilled_requests, capacity, history_coverage, forecast_version

Design direction

Observed trend plus a separate forecast band; no forecast when history is inadequate.

Related modules

C02, C06

Scale stage design · Roles: owner, platform

Purpose

Check whether a few willing contributors are carrying too many requests and make room for new participants.

What someone can do

Pause overloaded offers, ask for updated availability, and surface eligible members receiving little exposure.

Proposed mechanics

Compare accepted commitments with explicitly declared capacity; identify overloaded offers and eligible underexposed providers; ask before reallocating.

What to measure

Load against declared capacity and distribution of opportunities. This is workload planning, not a moral score.

Boundary to preserve

Do not infer burnout or personal wellbeing. Ask members directly and never penalize declining help.

When there is no data

No capacity data: request an update rather than assigning a utilization score.

Suggested data fields

offer_id, capacity, accepted_commitments, completed_help, decline_reason, member_preferences

Design direction

Capacity utilization by offer or aggregate group, without a moral or wellbeing score.

Related modules

C02, P07

Grow stage design · Roles: owner, platform

Purpose

Find the points where a current request waits too long for useful help.

What someone can do

Inspect the slowest stage and assign a steward, refresh capacity, or clarify a request.

Proposed mechanics

Join lifecycle timestamps by route; compute durations for completed stages and ages for open cases; report median, P90 and counts; drill into the slow stage.

What to measure

Median and 90th-percentile elapsed time at each stage, with sample size and still-open requests reported separately.

Boundary to preserve

Completed-only timing hides unresolved requests. Compare equivalent categories and cohorts, and never equate speed with quality.

When there is no data

No completed routes: show open-request ages and the observation window.

Suggested data fields

need_id, route_id, created_at, first_response_at, accepted_at, completed_at, closed_reason, cohort_end

Design direction

Use a three-stage timing strip and separate open-age bars. Never hide still-waiting requests.

Related modules

C03, C05, C06

Start stage design · Roles: owner, platform

Purpose

Show which specific needs lack enough available, eligible help so the organizer can recruit deliberately.

What someone can do

Open a gap, inspect constraints, and invite a provider or design a group program.

Proposed mechanics

Group current requests and available slots by compatible units and period; calculate indicative shortfalls; count requests lacking an eligible candidate; display age and coverage.

What to measure

Compare requests and slots with the same category, unit and period; separately count requests without any eligible candidate.

Boundary to preserve

A skill percentage is not service capacity. Unknown data is shown separately; a numeric surplus does not prove a match.

When there is no data

No current context: invite needs and offers before claiming a shortage.

Suggested data fields

category, need_id, offer_id, available_slots, unit, time_window, eligible_pair_count, oldest_open_days

Design direction

Paired bars or heat cells with numbers, units and words. Show a distinct unknown state.

Related modules

C02, C01

Grow stage design · Roles: owner, platform

Purpose

Help organizers see opted-in capability clusters at an event or venue without exposing exact member locations.

What someone can do

Select an event period and use aggregate demand to schedule a mentoring desk or skill circle.

Proposed mechanics

Accept a separate opt-in event check-in; bucket into broad zones and delayed time periods; deduplicate participants; apply suppression and differencing checks before rendering aggregates.

What to measure

Distinct opted-in participants per broad zone and time bucket, after deduplication and suppression. This is event presence, not precise proximity.

Boundary to preserve

The original “row away” idea becomes a broad-zone illustration. Never identify a seat, row, live individual position, or infer attendance from scans. Suppression needs a reviewed policy.

When there is no data

Below threshold: show “withheld” and a broader period; never reveal a small cell through subtraction.

Suggested data fields

event_id, entry_point_id, opt_in_check_in, broad_zone, time_bucket, shared_category, distinct_participants, publication_threshold

Design direction

A broad-zone tile map with withheld cells and a capability legend; never render an identifiable row or seat.

Related modules

F03, P09

Start stage design · Roles: owner, platform

Purpose

Make community readiness understandable through visible, defined measures of coverage, fit and completed help.

What someone can do

Inspect the weakest indicator and open its underlying queue.

Proposed mechanics

Compute each indicator from its own documented denominator; show components and freshness; open the source queue. A composite, if later adopted, needs a versioned formula and validation.

What to measure

Show three separate rates: current context / members; needs with candidate / open needs; confirmed useful outcomes / accepted introductions in the same cohort.

Boundary to preserve

These are operational indicators, not a percentage of human or latent potential. Any later composite must disclose weights, version and validation; it must not silently allocate money.

When there is no data

Missing denominator: show unknown, not zero or a healthy score.

Suggested data fields

member_count, current_context_count, open_needs, needs_with_candidate, accepted_introductions, confirmed_outcomes, period

Design direction

Three labeled progress indicators with numerator, denominator and period. The ring measures coverage only.

Related modules

P01, C02, C06

Grow stage design · Roles: owner, platform

Purpose

Show evidence of help moving through the community and give stewards the next useful action.

What someone can do

Review a proposed introduction, follow up on an accepted one, or open the evidence for completed help.

Proposed mechanics

Append route lifecycle events; deduplicate them; enforce visibility before the feed query; show only allowed details and actions; redact or aggregate the public variant.

What to measure

Timestamped lifecycle events with explicit states: proposed, permission requested, both accepted, help confirmed. Count unique outcomes separately.

Boundary to preserve

Pseudonyms and role labels can still identify people in small groups. Public feeds require aggregation, delay and publication approval.

When there is no data

No visible events: say no events in this period, not that every need is resolved.

Suggested data fields

event_id, route_id, stage, occurred_at, source_role, target_role, community_id, entry_point_id, visibility, confirmation

Design direction

Timestamped activity rows with explicit state chips and one next action. New events must not steal focus.

Related modules

C03, C05, C06

Scale stage design · Roles: platform, owner

Purpose

Reveal where approved partner bridges lead to completed help and where routes stall.

What someone can do

Select a community pair, inspect results and decide whether to expand or repair that bridge.

Proposed mechanics

Group authorized cross-community routes by directed pair; calculate accepted and completed layers within one cohort; suppress small sensitive cells; expose evidence for each approved aggregate.

What to measure

Directed community-pair counts, with accepted routes and confirmed outcomes as separate layers. Rates require the same route cohort.

Boundary to preserve

Use authorized aggregates. Geographic arcs require verified organization coordinates and a real basemap; the prototype is a labeled network matrix.

When there is no data

No approved routes: show an empty bridge opportunity, not invented links.

Suggested data fields

source_community_id, target_community_id, route_id, cross_route_count, successful_outcomes_count, period, agreement, coordinates_source

Design direction

A labeled matrix first; network arcs or a geographic view only when real coordinates and permissions exist.

Related modules

P15, C06

Start stage design · Roles: platform

Purpose

Give operators inspectable evidence about trackers, processors, sponsorship rules and storage configuration.

What someone can do

Inspect evidence, investigate an unknown destination, and approve or restrict a sponsor integration.

Proposed mechanics

Inventory scripts, destinations and processors; run scoped checks; record evidence and time; separately review sponsor alignment; require a reviewer before publishing claims.

What to measure

Record findings and coverage per test. Contextual match accuracy is relevant reviewed deliveries / reviewed deliveries; it is not a privacy audit result.

Boundary to preserve

Zero findings in a scoped scan is not a guarantee of no trackers. Region claims need evidence for storage, backups and subprocessors. No “100% secure” badge.

When there is no data

No fresh audit evidence: show not verified with an owner and review task.

Suggested data fields

audit_id, checked_at, scope, network_destination, processor_inventory, campaign_id, reviewed_match_count, storage_region, evidence_link, reviewer

Design direction

Audit rows with scope, freshness, reviewer and evidence. Missing checks remain visibly unverified.

Related modules

P08, P12

Grow stage design · Roles: platform

Purpose

Make the proposed 50% net-profit pool and community allocation weights transparent before they become payable terms.

This entry preserves the earlier net-profit-pool design. The announced per-sale partner program is different. Read the economic integration note before implementing it.

What someone can do

Adjust the hypothetical weighting, inspect each community’s calculation, then submit a policy for governance approval.

Proposed mechanics

Define net profit and eligible communities; choose an explicit scenario pool rate and upgrade-versus-outcome weight; normalize both bases; calculate shares and reconcile cents; approval creates a new policy version.

What to measure

Pool = defined distributable net profit × approved pool rate. Scenario shares normalize an explicit mix of upgrade share and confirmed-outcome share across eligible communities.

Boundary to preserve

The example is not an approved contract. Do not reward clicks or inferred social worth. Handle zero denominators, eligibility, refunds, rounding and disputes explicitly.

When there is no data

No policy or eligible basis: show a simulation only; no payable amount.

Suggested data fields

net_profit_definition, profit_period, pool_percent, community_id, upgraded_members, eligible_outcomes, upgrade_weight, policy_version, adjustments, approval

Design direction

Editable assumptions and a community allocation table showing every basis and calculated result.

Related modules

P11, C06

Grow stage design · Roles: platform, owner

Purpose

Give the public an understandable picture of participating communities and specific confirmed forms of help.

What someone can do

Choose a reporting period, inspect the methodology and publish a reviewed aggregate snapshot.

Proposed mechanics

Choose a reporting period; count communities meeting a defined activity threshold; aggregate confirmed outcome types; run publication checks; refresh only after evidence is approved.

What to measure

Count communities meeting a published activity definition and distinct confirmed outcomes by type. Mentorships, projects, ventures and volunteer work have different evidence.

Boundary to preserve

A connection is not a venture founded; a signup is not a shift completed. Avoid “transformed” or “self-sustaining” unless measured. Public view is a preview, not an access-policy change.

When there is no data

Insufficient publishable data: explain the pilot and omit unsupported headline claims.

Suggested data fields

community_id, activity_definition, outcome_id, outcome_type, confirmed_at, publication_consent, period, cohort

Design direction

A quiet connected-node visual and large outcome cards with methodology. Do not imply live activity in a static sample.

Related modules

P13, P16

Grow stage design · Roles: platform, owner

Purpose

Show how much money actually returned to communities and what portion was later confirmed as reinvested.

What someone can do

Inspect a period, open settlement evidence and review a consented reinvestment story.

Proposed mechanics

Sum settled transfers by period and currency, net of reversals; count unique recipient communities; link independently reported reinvestment receipts to eligible transfers.

What to measure

Cumulative settled transfers net of reversals; distinct recipient communities; verified reinvested amount / eligible settled amount for a defined period.

Boundary to preserve

“Waqf multiplier” is the source concept, not proof of endowment status or economic multiplier. Keep routed transaction volume, platform profit and community payouts separate.

When there is no data

No settlement: show pending allocation separately. Unreported reinvestment stays unknown.

Suggested data fields

settlement_id, community_id, paid_amount, currency, settled_at, refund_adjustment, reinvestment_receipt, designated_fund

Design direction

Cumulative paid-return line with period totals, receipt drill-down and an unknown reinvestment state.

Related modules

P11, C14

Grow stage design · Roles: platform, owner

Purpose

Let a public report explain its data practices with scoped, dated evidence instead of unsupported absolute claims.

What someone can do

Open the evidence behind a claim and request a refresh when it expires.

Proposed mechanics

Create each claim with scope and evidence; assign a reviewer and expiration; publish only approved claims; automatically mark expired or missing evidence for refresh.

What to measure

Published claims carry the latest evidence date and scope. Unknown, pending review and verified within scope are distinct states.

Boundary to preserve

“0 data brokers”, “0 trackers” and EU storage claims each need independent evidence. Never derive a compliance guarantee from a Boolean field.

When there is no data

No evidence: display not verified and a clear description of the intended policy.

Suggested data fields

claim_id, claim_text, scope, evidence_link, checked_at, expires_at, reviewer, publication_approval

Design direction

Trust cards that show status in text, evidence date and scope. Keep claims independent.

Related modules

P17, P09