Understanding the Demo

The live platform at karmyq.com runs a continuous simulation of a mutual aid network based in Portland, Oregon. This simulation exists so you can see what Karmyq looks like when it is actually being used — not a wireframe, but a living community.

What You're Seeing

The platform currently shows a simulated network of neighbors helping neighbors across several Portland communities: the Portland Mutual Aid Network, Southeast PDX Helpers, PDX Parents Co-op, Portland Tool Library & Share, and several professional service networks.

All accounts with @test.karmyq.com email addresses are synthetic. Their activity — requests for help, offers, completed matches, trust connections — is generated by a simulation engine running continuously in the background.

How Activity Is Generated

The simulation engine runs 10 concurrent workers, each independently acting as a simulated community member. Workers create help requests, offer assistance, complete matches, submit feedback, call dibs on requests, and participate in community governance — all through the same APIs a real user would call.

This means the trust graph, karma scores, and match history you see are the result of real platform behavior, not seeded test data.

What Real Users Would Look Like

In a real deployment, each of these interactions would be a person. A neighbor without a car asking for a ride to a medical appointment. A parent needing a school pickup covered. Someone with tools to lend finding someone who needs them. The simulation reflects these real patterns so evaluators can see the platform as it would actually be used.

Trust Graph

The trust network shows how trust has accumulated between simulated users through repeated positive interactions. Every completed match strengthens the trust edge between the helper and the person they helped. This is how real trust networks form — through doing things together over time.

Social Karma

After each completed match, both participants rate the interaction on helpfulness, responsiveness, and clarity. These ratings feed the Social Karma system, which surfaces patterns of good community participation without reducing people to a single number. The karma data you see reflects real platform feedback flows, not pre-loaded scores.

Tester Account (for evaluators)

To explore the platform with a rich, realistic profile already wired up, sign in with the primary tester account:

maria.reyes@test.karmyq.com / password123

This account is the most complete state in the demo: 15 active communities, 28 trust edges, 33 connections, 19 created requests, hundreds of helper and requester matches, and an active provider profile. It exercises the dashboard, the community pages, trust surfaces, dibs/matching, and provider offers without any setup.

If you want a plainer, member-only perspective (no provider profile, fewer communities), use the fallback:

aisha.white6964@test.karmyq.com / password123

All simulated accounts share the password password123.

Auditing Demo Data Quality

The demo data is regenerated continuously, so its quality is checked with a repeatable read-only script rather than by hand: scripts/audit-demo-data.sql. It reports membership-count drift, pulse helpers who are not members of the community being rendered, open requests with no active community link, and a ranking of the richest tester accounts.

Run it against the demo database (read-only):

scp scripts/audit-demo-data.sql ubuntu@karmyq.com:/tmp/audit-demo-data.sql
ssh ubuntu@karmyq.com "docker cp /tmp/audit-demo-data.sql karmyq-postgres:/tmp/audit-demo-data.sql \
  && docker exec karmyq-postgres sh -c 'PGPASSWORD=\$POSTGRES_PASSWORD psql -U \"\$POSTGRES_USER\" -d \"\$POSTGRES_DB\" -f /tmp/audit-demo-data.sql'"

Trust truth audit (Sprint 98)

A second read-only script, scripts/audit-trust-truth.sql, checks that trust relationships describe the same truth across layers: trust-edge endpoints that are still active members of the edge community, exchange connections backed by a completed match, cached social_distances rows with valid community context, provider shared-communities active on both sides, and dibs candidates that share an active community. Run it the same way (swap the filename). Findings and dispositions live in docs/bugs/sprint-98-trust-truth-audit.md.

Maria's two guided stories (Sprint 116)

The demo rehearses two contrasting relationship stories for Maria through ordinary APIs only:

• Ordinary story — a richly connected, cross-community helper (a short trust path, several shared people) so the reciprocal lens reads as a real neighbourhood, not an empty ring.
• Provider story — a low-overlap provider, shown as a deliberate contrast.

Rehearse with npm --workspace @karmyq/simulation-service run rehearse:maria-relationship (dry-run by default; add -- --apply to mutate). It refuses to apply a story that falls below the rich-overlap floor, seeds no trust edges, and prints the verified request/match/offer IDs used to configure the read-only demo session.

The rehearsal consumes the privacy-safe neighborhood API, whose nodes use user_id (not the internal graph field id). It normalizes both shapes before measuring overlap; a dry run that reports an unachievable floor must never be followed by --apply.

An apply run is resumable: always rerun dry-run after an error before retrying mutations. In the Sprint 116 live rehearsal, all four story records committed before a post-insert provider-notification lookup returned a false 500; reconciliation recovered the authoritative IDs without duplicating data.

DEMO_PERSONA_EMAIL also excludes Maria from random simulation workflows. This keeps the surrounding synthetic community alive while preventing the simulator from accepting a competing proposal and invalidating the stable guided story.

The read-only demo session (PR C)

karmyq.com/demo walks these two stories with no account and no writes. POST /auth/demo-session issues a 30-minute token that carries sessionMode: 'demo_read_only'; the shared auth middleware rejects any mutating HTTP method server-side, and the /demo page shows no Accept/Decline/Submit controls. No refresh token is issued — the tour simply expires.

To enable it, set the four IDs printed by the --apply run plus the persona into the demo environment (see .env.demo.example): DEMO_SESSION_ENABLED=true, DEMO_PERSONA_EMAIL, DEMO_ORDINARY_REQUEST_ID, DEMO_ORDINARY_MATCH_ID, DEMO_PROVIDER_REQUEST_ID, DEMO_PROVIDER_OFFER_ID. The persona must be an active, non-admin @test.karmyq.com account, and both stories must be coherent (Maria owns each request; the match/offer hang off the correct request) — any mismatch returns one opaque 503 DEMO_UNAVAILABLE.

How the Demo Is Built (Sprint 117)

The demo now begins from a deterministic, age-aware synthetic baseline rather than pure open-ended simulation. A single guarded reset establishes a compact, curated history — a set of Portland communities and neighbours whose completed exchanges, trust connections, and karma are derived from the same rules the live platform uses, aged relative to one reset moment (some exchanges days old, some months old). After the baseline is in place, ambient synthetic activity continues to evolve the wider population.

A small protected core of people — including the narrative persona and her closest connections — is held stable so the guided story stays coherent and is never altered by ongoing simulation. The persona is an ordinary active member (never an administrator).

Because the platform models real time, demo content behaves like the real product:

• Fresh vs. aging: recent requests are open; older ones expire on the normal 60-day schedule.
• Designed to forget: content past the retention window is redacted to a [forgotten] sentinel, exactly as it would be for real users — the demo demonstrates the forgetting behaviour, it does not hide it.
• Finite live stories: the guided persona's live decisions are real, finite, and rotated explicitly before they age out.

Everything you see is illustrative synthetic data — real numbers and names would belong to real people. It is not a frozen screenshot; it is the actual product running on curated, truthful history.