Real Work, Real Money

0. Where we landed tonight, and what to read

Today the project changed shape three times, each time on purpose. This morning the spec still treated the app as tabs and sections. By tonight: every member moment has been rebuilt from first principles (The Working Organization, v1.2), the daily “edition” is gone in favor of the Account (your agent tells you what happened since you last looked), the ally became ambient (it hears you and others everywhere it has a presence, and weights what it hears by source), and design round 2 integrated the five interface paradigms into one app: a single conversational surface standing on a living ground, with a signature deck that only exists when something needs your signature.

Reading order for tomorrow: this document first (it’s the plain-language one), then The Working Organization (the system in full), then design-r2/INTEGRATION.md and the Key Screens (what we’re building), with the motion/realm/making specs and the three prototype cuts as reference. Everything is linked from the team page.

This document exists because a fair criticism landed tonight: too much of our language sounds mystical. Allies, realms, ceremonies, weather. Every one of those words names something a contractor, a lawyer, or an ops manager already understands. This brief makes the translation, then walks through the three things that matter most and that our documents have under-explained: how people actually work together, how money actually moves, and how someone builds a real practice here. It is deliberately slow.

1. The plain version

One table, no mystique. The left column is our word; the right column is what a working professional would call it.

Nothing in the system requires believing anything. It requires exactly one behavioral change: you stop operating software and start directing an agent. Everything else is ordinary work.

2. How people collaborate — one real job, end to end

No abstractions; one engagement, walked slowly. The cast is deliberately awkward, because real coordination is: a project lead in Charleston (Ana, Service Alliance member), a designer in Manila (Joy, member, works Telegram-first, +12 hours), a retired logistics manager (Frank, member, uses email and nothing else, doesn’t own a smartphone he likes), a bilingual college student (Luz, member, lives on her phone, available nights), and the client — a county food bank director named Ruth who is not a member, has no wallet, no app, and never will.

The job arrives. Ruth heard about Service Alliance from a board member. She emails the address on their site — or fills the contact form, which is a made-thing page carrying the organization’s verifiable credential. Either way, her message reaches Service Alliance’s Envoy (its outward-facing agent), which does what a good office manager does: answers within minutes in plain English, asks three clarifying questions, and opens an intake record. Ruth needs a volunteer scheduling system for four distribution sites and Spanish-language outreach materials, and she has an $8,000 grant to spend. No member has done anything yet.

The job is shaped. The Drafter turns the intake into a scoped engagement: deliverables, timeline, budget, and a proposed team profile (project lead, designer, logistics advisor, bilingual writer). Under Service Alliance’s policies — its accumulated rules, set by past votes — engagements under $10k don’t need a member vote; they need one member with lead standing to accept. Ana’s ally knows her availability, her rate, and that she’s been asking for exactly this kind of civic work. It presents the engagement to her — not as a notification, but as the lead claim in her Account, with the pay stated: lead role, $2,800 of the $8,000, six weeks. She says “yes, if Joy is on it.” That sentence is the acceptance.

The team assembles without recruiting. Ana’s ally and the engagement record go looking for the rest — not by broadcasting, but by asking the allies of members whose skills, rates, and stated availability match. Joy’s ally wakes her to a claim in Tagalog-inflected English she’s set as her register: design role, $2,200, deliverables listed. Frank’s ally emails him — a plain email, because that’s Frank’s whole interface: “Service Alliance job, logistics advice on volunteer scheduling across four sites, ~10 hours over six weeks, $900, reply YES or call me.” He replies YES from his kitchen table. Luz gets hers on Telegram at 11pm, which is when she’s awake: outreach writing, $1,100. Everyone said yes in their own channel, in their own language register, at their own hour. The engagement is now an alliance — team, charter (the scope), shared wisdom (Ruth’s intake, the site data), rhythm (Tuesday check-in), and a budget line — and every member’s ally now carries its context.

The work happens — and this is the part to get right. It is not votes and markets. It is:

• Asks. “Who can get the site survey done before Thursday?” — Ana says it once, to her ally; the ask reaches Frank as an email and Luz as a Telegram message, phrased for each of them, with what it pays if it’s extra-scope. Nobody CCs anybody. Nobody is “on” an app.
• Handoffs. Joy finishes the scheduling flow mockups at 3am Manila time. The handoff is an artifact with its context attached — Ana wakes to it in her Account with Joy’s three open questions already extracted and Frank’s relevant constraint (Site 3 has no wifi) already pinned to question two. Nothing is lost in the handoff, because the handoff is the record.
• Reviews. Ana reads the mockups on her porch and talks — voice, to her ally — for four minutes about what’s wrong with the check-in flow. Joy gets it as structured feedback in the morning, in her channel, with Ana’s tone intact but her rambling organized. Frank gets the one question that concerns logistics, by email.
• Meetings — real ones. Twice in six weeks the humans actually meet: a video call with Ruth at kickoff (her calendar was negotiated between her assistant and two allies; nobody sent a “when works for you?” chain), and one working session when the team disagrees about paper backup schedules. That disagreement is not a vote and not a market. It’s a conversation — with each ally having briefed its member beforehand and the alliance’s record holding what was decided and why. The Sentinel’s only involvement: it noticed Joy going quiet-agreeable two exchanges in (harmony drifting toward accommodation) and nudged her ally’s pacing so her actual objection surfaced. It did. The paper backup happened. That’s HEARTS in practice — not therapy, just a meeting that didn’t steamroll the quietest person in it.
• The client experience. Ruth gets a plain-English email every Friday from “Service Alliance” — two paragraphs, what happened, what’s next, any decision she owes. She replies in email; her replies become context. She never knows there’s a graph. In week four she asks for a second Spanish dialect variant; the Envoy prices the scope change ($400), Ana approves it with one word, Ruth gets a revised total. No change-order PDF ever exists, but the change order absolutely exists — it’s in the record, signed.
• Status. Nobody writes a status report in six weeks. Everyone’s Account renders their own view of the same underlying facts: Ana sees the whole board; Frank sees logistics and his hours; Ruth sees Friday emails. The status report is dead; the status is alive.

The job closes. Deliverables are artifacts; Ruth signs off by email; the Envoy invoices her — a real Stripe invoice, $8,400, to the food bank’s card — and the money lands in Service Alliance’s treasury. Then the split executes exactly as recorded at acceptance: Ana $2,800 + the $400 change-order lead share, Joy $2,200, Frank $900, Luz $1,100, Service Alliance’s operating share the remainder per its policy. Every member’s Account shows their payout with the receipt chain; every payout appears on their next Seal. Total governance events in six weeks of real work: zero votes (the engagement was under the threshold), one policy consulted, two meetings, one Sentinel nudge. The rest was people working, with agents carrying the coordination weight — across four time zones, three channels, two languages, and one participant who never joined anything.

That is what “orchestration with a very wide range of people in all kinds of circumstances” means, mechanically.

3. How the money works — slowly and completely

Where money comes from. Four sources, all boring: (1) clients and customers pay real money for real work — Stripe invoices, cards, bank transfer, fiat; (2) members pay $100 once, for life, to join Kinship Duna (the founding round: 10M $KIDUNA issued at close; your remaining balance converts at the launch price); (3) organizations charge for what they make and run (BiHome’s research service, an event’s tickets — tickets are codes, remember); (4) compute is metered at 7× API cost against member balances, which is the platform’s margin.

Where money sits. Every member has a wallet (created at signup, key custody on the web behind view/hide). Every duna has a treasury. Client money lands in treasuries; splits move it to member wallets. Pre-launch everything is fiat denominated in dollars; tokens come at the founding-round close, and each duna may eventually run its own compute currency — but nothing in Section 2 waited for a token, and that’s the point. The token is not where the money story starts; the invoice is.

How pay gets agreed. At acceptance, in writing, in the engagement record — like any contract: fixed splits (“$2,800 of $8,000”), hourly with caps, or percentage. The ally states pay when it presents work; saying yes accepts the terms; scope changes are priced and re-accepted the same way. There is no rate marketplace where humans underbid each other in real time, and there are no “bounties” as the default idiom — there are engagements with terms, because that’s how professionals already work. Markets (the pass/fail token mechanics) exist for what they’re actually good at: contested collective predictions and priorities. They are perhaps five percent of the system’s life. If our writing has made it sound like fifty, this document is the correction.

How pay gets executed. When the triggering event happens (client payment received, milestone signed, week ends), the recorded split executes as distribution events in the graph: treasury → member wallets, automatically, with the receipt chain attached. Nobody invoices a teammate. Nobody chases a check. The organization’s books are the same records the work created — the audit trail isn’t reconstructed for the accountant, it is the accounting. Members see money the way they see everything: a line in the Account (“Service Alliance paid out $3,200 — receipts”), a line on the Seal they sign.

Getting money out. Bank transfer / debit rails via Stripe now; Sphere later adds on/off-ramps and virtual bank accounts so a member in Manila or Mumbai participates fully without ever touching crypto. Or leave it in as compute. Or, post-close, hold tokens. Member’s choice, member’s wallet.

Growth pay (organizers). Bringing people in is recorded work: when you enroll someone (your code, your signature), lineage is recorded in the database, and your Clan — the downline — is tracked four generations deep. Commissions attach to exactly one event: a Compute purchase — a clan member exchanging USD or USDC for the duna’s Compute, including their initial purchase. Nothing else pays lineage: not work, not splits, not votes. The default schedule — every duna’s starting point unless changed, and Kinship Duna’s at launch — is Gen 1: 20% · Gen 2: 5% · Gen 3: 3% · Gen 4: 2% of the purchase. A duna’s Catalyst sets the schedule at founding; the Forum can change it afterward like any configuration. When and where it pays: a USDC purchase on-chain pays organizers immediately; a fiat purchase through Stripe shows in the organizer’s wallet as pending — earned and recorded, but not yet moved on-chain — and settles when the fiat bridges from the bank to the blockchain, expected monthly. And lineage is wholly optional per duna: a duna can run without codes or invitations at all (everyone walks in), or start invite-only and open the doors later.

The honest flags (counsel list, standing). Worker classification and tax treatment of member payouts (1099 posture until counsel says otherwise); money-transmission questions on automated splits; trust accounting for law-practice dunas; state insurance regulation for Lui Mutual; securities posture of the founding round (already with counsel). We name these in the team doc because pretending they’re solved is how projects like this die. None of them blocks Section 2’s engagement from running on Stripe + recorded splits tomorrow.

4. Building a practice — three professions, worked

4a. A consulting practice, from zero

Maya is an operations consultant. Fifteen years of supply-chain and nonprofit ops, tired of spending 40% of her time on business development, scheduling, and invoicing.

Month one — hanging the shingle. She joins ($100, names her ally, an afternoon of talking while it learns her: expertise, methods, rates, availability, the work she wants more of). Her methodology becomes wisdom (private — clients’ engagements can use it; nobody can copy it); her intake questions become a skill. Her ally now hears for her: in Seek where other members look for help, and out in people-space where her presence lives. She makes one thing — a one-page practice site with her credential embedded, born in three conversational exchanges — so anyone who finds her can verify who she is and start an intake without her lifting a finger.

The first engagement arrives as a claim: “Riverkeepers is drowning in volunteer intake — fits your background, $3,500, three weeks, their lead wants a call Thursday.” Her ally already checked the fit against her stated preferences and held two worse-fitting asks at the gate (they’re in the Account as one line, expandable, ignorable). She works the engagement like Section 2. When it closes, something important exists that consultants have never had: a sealed, verifiable track record — the scope, the deliverables, the outcome, the client’s sign-off, as artifacts. Not testimonials on a website; records another organization’s ally can check before hiring her. Reputation becomes portable and provable. Her rate goes up because the evidence is inspectable.

Month six — the bench. A bigger job needs three people. She forms an alliance — her bench: a researcher she trusts, a designer from the food-bank job. The engagement pays into the alliance’s split. Her practice is now sometimes-plural without being a company.

Year one — the firm, if she wants it. The bench keeps working together; they spin out a duna — her own organization, own treasury, own policies (the split formula the partners vote once, not per-job), own intake, optionally its own token much later. The Charterer and Registrar do the formation paperwork; the practice’s programs (intake, scheduling, drafting, invoicing, follow-up) are configured, not built. What Maya never built: a website (three exchanges), a CRM (the graph), a pipeline tracker (her Account), an invoicing system (treasury + splits), a scheduling assistant (her ally), a marketing funnel (her presence + enrollment). What she built instead was the only thing clients actually pay for: judgment, applied. The 40% overhead became roughly zero, and the overhead was the barrier to solo practice. That’s the pitch to every professional we onboard, in one sentence: the back office is agents now.

4b. A law practice

Dan is a West Virginia attorney, solo, general practice with a nonprofit specialty. The system treats his license as what it is: a credential that gates signatures.

His practice duna is configured so that anything constituting legal advice or a filing routes to his credentialed Docket — agents draft, assemble, research, and remind; only Dan signs. Concretely: engagement letters are codes (scope of representation, fee terms, conflict disclosures — signed by him, verifiable by the client, revocable); conflict checks run before intake ever reaches him — a worker checks the would-be client against the graph of his existing matters and flags; matter files are secret-tier artifacts (privilege maps onto the privacy model directly: secret wisdom is unlisted, unembedded outside scope, access-logged); the regulatory corpus (WV code, DUNA law, filing deadlines) is wisdom the Librarian keeps current with change-watchers, so the research memo his ally hands him cites yesterday’s code, not last year’s.

His clients are Ruths — email and phone people. His presence does intake, scheduling, and status in plain English; his mornings start with the Account rendering his docket of matters: what moved, what’s due, the two things needing his signature, the one client call that actually needs him. Billing is recorded per-matter (flat or hourly), invoiced through the treasury; trust accounting (IOLTA) is explicitly on the counsel-list — we do not automate client trust funds until a WV ethics read says how.

The scale story: thirty dunas are filed and every one of them needs outside counsel sometimes. Their allies can see Dan’s availability, scope, and rates; a duna’s “we need counsel on X” becomes an engagement claim to Dan the same way Ruth’s job reached Ana. One lawyer, thirty organizational clients, zero business development — and Lui Mutual, when it comes, is this pattern with an actuary next to it.

4c. A consulting firm

The multi-member version of Maya, stated briefly because the pieces are all above: partners are members with lead standing and a split formula set by proposal (one vote when the formula changes, not per engagement); associates are members on engagement splits; the methodology is the firm’s skill set — versioned, Examiner-tested, propagated to every member’s ally, which is what “training” and “quality control” become; every engagement is an alliance with the client’s rep receiving human-grade communication in their own channel; business development is every member’s presence — the firm is findable and verifiable everywhere any member is; the firm’s reputation is its sealed portfolio. What the firm doesn’t employ: office manager, CRM administrator, billing clerk, resource-allocation spreadsheet owner. Those are workers now. What it does employ: consultants. The firm’s margin stops subsidizing its own administration.

5. What this asks of the build — tomorrow morning

Everything above runs on the worker roster we already specced (Part IV of The Working Organization) plus the design round 2 output. The morning agenda we propose:

1. Walk this document (30 min). Contest the money section hardest — it’s the newest.
2. Contest design-r2’s five disagreements (30 min) — especially “the ground is the home, not the Thread” and “the Commons ships as ground, not world.” We think the designer is right on both.
3. Cut missions for the week (60 min). Our proposed six, each mapping to specced workers: the presence spine (Switchboard + Telegram adapter + Gatekeeper — Section 2 is impossible without it); the money MVP (Stripe intake → treasury record → recorded splits → payout log; manual execution, automated records — legality-first, automation second); Renderer v0 (since-you-were-gone over our own repos and this site — we are members zero); Clerk v0 (cards with consequence statements, press-and-hold); the drift shader spike in Flame (INTEGRATION §5 + MOTION-SPEC §2 — prove ≤5% GPU idle on a mid Android); and the counsel packet (Section 3’s flags, one page each, to real lawyers this week).
4. Assign an open question each. Claiming one is how a workstream starts — that’s been true on paper; tomorrow it becomes true in fact.

The through-line for the meeting, and the sentence to hold when any discussion drifts abstract: a food-bank director with an $8,000 grant got a working system from five people on three channels in two languages, everyone got paid without an invoice between them, and nobody attended a ceremony. That’s the product. The rest is how.

Kinship Duna · kiduna.team · pairs with The Working Organization, design round 2, and the prototypes. Questions to Moto tonight; arguments welcome tomorrow.