ARCHITECTURE · OCTOBER 26

One field.
Many kinds of intelligence.

Prompts, context, loops and triggers connect the work. The shared structure makes each interaction purposeful and each effect accountable.

01 · INPUT

Intent + context

Chat, voice, a page action or a permitted automation.

02 · DECISION

Route or clarify

Use purpose, identity, current work and permitted knowledge.

03 · EFFECT

Act + record

An Ally prepares. An authorized Actor executes. A receipt closes the loop.

Envoy / Mask · Scout · Guide · Ki · Actor ↩ Results return to the same conversation and work record

FOLLOW A REQUEST

    Illustrated target behavior, not a live agent execution.

    October 26 design direction, reconciled from the Daily Kiduna Sync and one-page whiteboard. This is a target architecture and engineering interpretation. It is separate from the screen specifications and does not assert that every described service already exists.

    The central idea

    A member’s words, a button tap, a voice request or an automation produces an intent with context. A decision layer determines where that intent belongs. The selected Ally uses its configured knowledge and capabilities; an Actor performs a bounded operation; the resulting evidence and state return to the same conversation and page.

    The recurring loop is intent + permitted context → route or clarify → act within authority → record the result → continue or notify. DUNAs provide purpose, governance and resource boundaries. They do not create isolated social silos: permitted collaboration can cross them. [Call: 00:24:05–00:26:58, 00:32:32–00:36:28, 01:38:38–01:43:57.]

    Product surfaces

    Surface Role Release boundary
    Kiduna Live Explore, join, back, claim, create Initiatives/Activities/Actions, chat and vote Immediate mobile priority in the call.
    Kiduna Studio Author DUNAs, Maps, Decks and more complex structures Future desktop authoring; not added to mobile Create.
    Public web / kiduna.app handles Discoverable, linkable organization and work pages, search and AI indexing, app entry Future delivery surface. Domain redirects, rendering and authentication are not settled by the whiteboard.
    kiduna.design Current prototype, historical references, requirements, architecture and handoff Engineering review site, not the live operational backend.

    Preserve a stable URL identity for every object and retain old aliases. The whiteboard’s lunchbreakers.com is an illustrative domain; the current supplied profile uses lunchbreakers.food. [Call: 00:06:58–00:19:45; whiteboard top-right.]

    Work belongs somewhere

    The Big Kiduna ecosystem → DUNA → Initiative → Activity → Action.

    A DUNA can host many Initiatives. Lunchbreakers’ school-meal Initiative is one example; workplace meals and elder meals were suggested possibilities, not implemented records. Activities are finite contributions toward an Initiative. Actions are the concrete things a participant or agent can do inside an Activity. Dependencies apply when necessary; the UI must not imply every Action is always sequential.

    Create inherits its parent: DUNA creates Initiative; Initiative creates Activity; Activity creates Action. A shortcut without a single Activity must ask which Activity owns the new Action. This is why the prototype’s Initiative-level Create Action opens a choice of Lunchbreakers Activities. Classification such as Mission, Campaign or Movement belongs on the Initiative presentation. Preserve older cycle IDs, provenance and accepted obligations when mapping the visible hierarchy. [Call: 00:08:54, 00:37:45–00:41:02, 00:50:26–00:59:02, 01:52:58–01:54:38.]

    Allies and Actors

    Role Represents / performs Boundary
    Envoy A member’s preferences, context and delegated intent Acts only within that member’s permissions.
    Mask An alternate member representation in a context Same underlying member authority; public identity disclosure stays restricted.
    Scout Collective work: DUNA, Initiative, Activity or Action Carries its purpose, sources, fit rules and capabilities.
    Guide An Alliance Coordinates the group within its membership and authority.
    Ki The shared field and conversational coordination Maintains continuity; can synthesize or clarify.
    Actor A bounded operation: retrieve, prepare, send, change state or dispatch an authorized payment Enforces service permission and records a receipt; not a free-standing social identity.
    Jev / decision adapter Select a bounded destination or evaluate a bounded question Routing is distinct from review and legal/governance authority.

    The discussion initially called DUNA helpers Guides, then settled on Scouts for collective work and Guides for Alliances at 00:48:17–00:50:26. A later sentence and whiteboard tile also list Alliance under Scout. This handoff uses the explicit taxonomy decision and flags the overlap for migration review. Older Master/Governance wording that Scouts represent themselves remains historical context; it is not silently rewritten in the bundled release.

    Six attributes, one versioned configuration

    Every Ally resolves Wisdom, Instructions, Tools, Automations, Skills and Vibes. Wisdom is sourced knowledge and retrieval context. Instructions define purpose and behavior. Tools expose permitted capabilities. Automations define loops, schedules and triggers. Skills are reusable, versioned workflows. Vibes express presentation and interpersonal style; their detailed runtime contract remains to be specified.

    The call describes existing Allies as subagents of Ki. The target improvement is consistent context and capability composition, not an assumption that a separate process must be permanently running for every object. The same skill can be reused with different DUNA or work context. Loading a skill never grants tool permissions. [Call: 00:19:45–00:26:58, 01:08:50, 02:01:40–02:07:03.]

    Routing and clarification

    1. Normalize typed text, voice, page action or trigger into an intent envelope.
    2. Resolve the authenticated member, active Envoy/Mask, current DUNA/work object, conversation, revision, relevant memberships and consent.
    3. Retrieve only permitted, relevant context from structured records, the relationship graph and sourced wisdom. Do not load unrelated private data merely because it exists.
    4. Select a destination, ask for missing facts, propose a safe reroute, or escalate. Record the rationale and references used.
    5. Load the destination’s pinned six-attribute configuration and relevant Skills.
    6. Prepare an action, then enforce permissions, prerequisites, revision and any required approval at the service boundary.
    7. Record a result/receipt, update canonical state and show truthful progress in both chat and the page.

    For ordinary routing the call favors one decision model, with Jev suggested as default and an image-capable decision adapter when needed. It does not mandate running two models for every message. Exact model IDs, thresholds and current prompts are required implementation inputs; spoken model names in the transcript are not verified vendor configuration. A route decision is not authority to send, spend, publish or change policy. [Call: 01:13:20–01:26:52, 01:34:13–01:43:57.]

    Shared data and context

    Store / interface Canonical responsibility
    Structured state IDs, versions, parents, membership, visibility, status, drafts, submissions, mandates and receipts.
    Relationship graph Member/Ally/DUNA/Alliance/work relationships, collaboration and permitted matching.
    Wisdom retrieval Source-addressable chunks with DUNA/entity, owner, version, review date, visibility and citations.
    Artifacts / evidence Original files, immutable submitted revisions, provenance and access policy.
    Financial and compute ledgers Separate monetary and KI units; restrictions, reservations, settlement receipts and reconciliations.
    Event / job stream Real stage receipts, triggers, retry keys, causation, checkpoints and delivery status.

    These are logical boundaries, not a decision to introduce a particular database vendor. Authorization applies before retrieval and again before execution. Pages and conversation widgets invoke the same command layer and observe the same canonical records. User onboarding interests and change categories must be editable in profile; Home, Current Location and work geography remain separate. Progress messages name the actual operation performed instead of repeating a generic checklist. [Call: 00:34:50, 01:19:54–01:25:52, 01:50:50–01:52:58.]

    Creation, remix and publication

    The current flow described by engineering is: description → variable clarification questions → research → draft Activities/resources/steps → iterative edits → deterministic publication. The call says much of this currently shares Ki’s system prompt; the exact prompt was requested but is not in these attachments. Dynamic DUNA context, narrower Skills and routing are the target improvement.

    Keep a durable draft ID and revision through clarification, research, failure and retry. Do not rerun completed research without cause. Remix by a different catalyst branches from the source; editing one’s own published Initiative creates a revision, not silent destructive replacement. The current prototype implements Initiative remix; Activity remix and its authorization remain an implementation gap. Publication validates parent, purpose, conflicts, permissions and readiness, then commits atomically. Unsupported external tools and time-based Activities were explicitly still awaiting testing. [Call: 01:04:34–01:08:50, 01:46:12–01:58:14.]

    Participation, completed work and review

    An Activity template is reusable; an instance binds the actual place, time, group and scope. A member can help across geography. In-person requirements are explicit commitments, not inferred from their Home address. Before claiming a matching instance, check for existing completed work and offer its reviewed findings and collaborators rather than asking someone to repeat it. Completed records remain discoverable in history / Go Deeper.

    Actions collect information from the member, searches or connected tools, and may wait for a response or prerequisite. Action completion, Activity completion, evidence acceptance and payment are separate events. Review binds to the exact submission revision. The call describes using Jev and a second evaluator for work judgment, comparing differences, then Ki and ultimately authorized DUNA Mages for unresolved cases. Implement this as a review policy with explicit reviewer authority and escalation; do not confuse it with the single-model router. [Call: 01:05:41–01:08:50, 01:18:15, 01:27:25–01:32:58, 01:58:14–02:03:32.]

    Governance and resource flow

    The Big Kiduna treasury can support DUNA purposes through authorized allocations. Reviewed participation records can inform a DUNA distribution proposal. The requested direction is periodic, voted distributions rather than an automatic per-Activity payout. Research and recommendation lead to a proposal; an adopted rule determines a decision; the decision creates a mandate; an authorized Actor executes it and records receipts.

    The call’s “every other week” cadence is product intent. Lunchbreakers’ founding draft proposes windows on the 10th–14th and 24th–28th; the older Governance sources describe different windows. No global scheduler or adopted calendar is inferred. Currency, timing, contribution weighting, payroll/contract obligations, custody and approval must be configured from actual adopted DUNA rules. KI compute is not USD and is not converted or added to monetary holdings. Historical accepted compensation terms remain protected. [Call: 00:41:02–00:42:50, 01:10:25, 01:38:38–01:42:30, 01:55:43–01:56:48; policy source; Governance reconciliation.]

    Two concrete paths

    Out-of-scope cricket request in Lunchbreakers. The DUNA Scout detects a purpose mismatch, explains it through the member’s representation, and returns the original intent plus fit rationale to the router. The router suggests the appropriate DUNA. Keep the member’s draft, visibility and consent; do not silently move or publish it. [01:32:58–01:38:38.]

    Investigate school meals. Resolve the school and instance; reuse permitted completed findings; gather menus; store source references; ask the nutritional Scout to analyze; prepare a farmer email if needed; the member approves the specific send; record the response, evidence and review. The reviewed contribution can later inform a proposed distribution. Completing the email or Activity alone does not transfer funds. [00:55:38–01:03:28, 01:29:58, 01:58:14–02:03:32.]

    What still needs an engineering answer

    Obtain the actual Ki/Ally prompts and runtime configuration; confirm router model selection; map IDs and ACLs across all stores; settle Mask disclosure policy; pin Skill and automation versions; define routing confidence, timeouts and loop limits; settle review thresholds and authorized Mages; validate time-based and external-tool workflows; configure an adopted governance calendar and financial authority. The whiteboard is conceptual and contains no deployable API specification. The service profile in this kit is an explicit engineering proposal for those boundaries.

    SOURCE MATERIAL

    From the call to the system.

    Architecture uses timestamped call references and the original whiteboard. Conflicts and added engineering recommendations are called out in the specification.

    View the whiteboard and readable detailsOctober 26 whiteboard showing DUNA and work hierarchy, six Ally attributes, routing and creation flows
    Whiteboard detail: Ally types and six attributesWhiteboard detail: prompt, context, routing and cricket reroute example