# OURS ## Product, movement and implementation blueprint **Status:** Founding direction v0.1 **Date:** 25 August 2026 **Canonical public name:** OURS **Public ritual and domain:** OURS TODAY · `ourstoday.com` This document records the agreed direction for OURS and separates adopted decisions from hypotheses that must be tested. It is intended to become the source of truth for product, design, governance and implementation work. ### Decision language - **Adopted** — part of the founding direction until explicitly changed. - **Hypothesis** — a proposed mechanism or threshold that requires evidence. - **Future decision** — intentionally unresolved until a pilot provides enough information. - **Concept data** — fictional numbers or examples used only to make a design inspectable. --- ## 1. Founding conviction ### Adopted thesis Software creation is becoming abundant. A useful product can increasingly be assembled in days rather than months. This does not remove the difficult parts of creating a durable alternative: trust, coordination, migration, safety, operation, governance and sustainable economics. Attention is abundant but unstable. The scarce resource is **credible collective commitment**: - knowing that an alternative solves the real problem; - knowing that the people who make it valuable will move together; - knowing who will operate it tomorrow; - knowing that the ownership promise is enforceable; - knowing that the product can survive without exploiting its users. OURS turns: > **attention → commitment → proof → coordinated migration → member ownership** The central product promise is: > **Software can be copied. A network cannot. OURS makes networks movable.** ### What OURS is OURS is a coordination layer where people assemble around missions, test daily builds, commit their communities, switch together and become members of the products they make viable. It is a market for human commitment—not an idea marketplace, software generator, crowdfunding leaderboard or speculative exchange. ### What OURS is not - Not an AI coding interface. - Not a popularity contest for startup ideas. - Not a token, crypto asset or market in tradable ownership. - Not a replacement for product leadership. - Not permanent voting on every interface decision. - Not another centralized landlord for otherwise independent communities. - Not a promise that software, moderation, safety, support or operations cost zero. ### Independence OURS is a separate company and movement with its own brand, entity, repository, domain, product thesis and community. It must not inherit another product's positioning or architecture by default. --- ## 2. Brand foundation ### Adopted brand architecture | Layer | Name | Role | |---|---|---| | Movement and federation | **OURS** | The enduring public idea and member institution | | Daily product and public ritual | **OURS TODAY** | The live mission market, daily builds, decisions and switches | | Canonical domain | **ourstoday.com** | The primary public address | | Secondary domain | **ours.biz** | A short defensive redirect, if checkout and renewal costs are reasonable | | Product institutions | **Cell 001, Cell 002…** | Mission-specific member organizations | ### Primary message > **Everything can be built. What should become ours?** Supporting line: > **Join a mission. Prove the product. Switch together. Own the result.** Additional useful language: - **Builds are cheap. Moving together is hard.** - **OURS does not monetize attention. It compounds commitment.** - **A mission survives its first product.** - **Watch what is moving. Help move what matters.** - **From products we use to products we govern.** ### Voice OURS should sound direct, civic, optimistic and operational. It should be bold without pretending that collective ownership makes difficult trade-offs disappear. Prefer: - mission, commitment, proof, member, steward, switch, cell, outcome; - exact thresholds, named responsibilities and visible costs; - “we are ready to move” rather than “disrupt the industry.” Avoid: - startup pitch language; - vague community language without rights or obligations; - “democratize” when the actual mechanism is not described; - financial-market language that implies price appreciation; - calling supporters owners before legal ownership exists. ### Domain and trademark status At the registry/RDAP check on 25 August 2026, the six proposed domains appeared unregistered. Registrar checkout, premium pricing and renewal pricing remain the final confirmation. `ourstoday.com` is the recommended canonical address because it supports the daily ritual, offers a credible `.com`, and makes the otherwise broad OURS name more distinctive. `ours.biz` has a strong secondary reading—“this business is ours”—but weaker mainstream trust. The public name is semantically strong but commercially crowded. Active uses include [ours.com](https://ours.com/) and [ours.network](https://ours.network/). Domain availability does not establish trademark clearance. Before public launch, obtain a licensed trademark and category-confusion review for the relevant countries and product categories. The legal entity name can differ from the public brand. --- ## 3. The unit is a mission, not an idea ### Adopted product ontology | Object | Definition | What may change | |---|---|---| | **Mission** | The enduring human outcome the cell exists to make true | Rarely; changing it reforms the cell | | **Thesis** | A falsifiable explanation of why a particular approach can win now | Must change when evidence disproves it | | **Product** | The current vehicle used to pursue the mission | Replaceable | | **Build** | Today's executable product proposal | Expected to change frequently | | **Proof** | Observed use, retention, outcomes, costs and safety evidence | Accumulates or invalidates the thesis | | **Cell** | Members, stewards, assets, treasury and governance pursuing the mission | Can grow, federate, reform, leave or close | A cell is: > **Mission × Thesis × Constituency × Institution** An idea confers no status, ownership or right to demand that something be built. A proposed mission earns a cell only when it has: 1. a specific affected constituency; 2. evidence of repeated harm or unmet need; 3. a falsifiable product and migration thesis; 4. named initial stewards; 5. a plausible unit that can move together; 6. a credible operating and economic loop; 7. safety and regulatory requirements that can realistically be met. If a product fails, the mission can survive and try another product. If the thesis fails, the cell must reform, become dormant or close. OURS must not preserve zombie cells simply because they once attracted attention. --- ## 4. The Mission Market ### Product role The front page of OURS TODAY is a live map of what people are uniting around. It should carry the urgency and readability of a market watcher without turning missions into financial speculation. The market grammar is useful: - momentum; - conviction; - thresholds; - named events; - visible movement; - public evidence. The speculative ontology is rejected: - no share price; - no market capitalization; - no tradeable influence; - no token; - no anonymous pumping; - no promise of appreciation. ### Heatmap semantics Every cell tile communicates: - **Area:** verified active commitments, not followers or page views. - **Momentum:** seven-day movement in testing, retention and conditional commitments. - **Stage:** signal, forming, building, usable, ready, switching or ours. - **Readiness dimensions:** product, migration, economics, safety and stewardship. - **Next unlock:** the concrete missing condition preventing progress. There should be no opaque universal “heat score.” A single score would hide weak retention, unsafe operation or nonexistent economics, and would quickly become gameable. Heat must be based on proof rather than attention. Discovery should deliberately reserve space for credible new and smaller cells so that yesterday's popularity does not automatically own tomorrow's attention. ### Every pixel must lead to action Clicking a cell must lead to one of five meaningful actions: 1. **Try today's build** — complete a real task and generate usable evidence. 2. **Commit to switch** — state explicit conditions under which the person or group will move. 3. **Bring my people** — assemble a bounded cohort without contact scraping. 4. **Contribute** — provide expertise, testing, migration work, documentation or capital. 5. **Help steward** — accept a named, reviewable responsibility. Actions must produce use, evidence or accountability. Likes and empty reactions should not drive cell progress. ### OURS TODAY as a daily ritual OURS TODAY should be finite and eventful rather than another infinite feed. A daily edition could show: - the mission gaining the most verified commitment; - builds that became usable today; - important decisions closing today; - cells that reached a switch threshold; - upcoming migration events; - one specific contribution that could unlock a cell. The goal is to make product creation engaging to watch while continually creating exits from spectatorship into participation. ### Design proposal Open the [interactive Mission Market design proposal](./mission-market.html). All people, cells, counts and momentum values in the design are concept data. --- ## 5. The central mechanism: Switch Together ### The Together Pledge The defining product primitive is a conditional commitment: > “I will move when this product passes these tests, this many people I rely on also commit, and these named operating conditions are met.” A pledge should contain: - the person or bounded cohort making it; - the cell and product version involved; - the minimum participation threshold; - required product capabilities; - required safety or operational checks; - an expiry date; - the verification method; - the proposed switch window; - consent and privacy boundaries; - the right to withdraw before activation. Example: > “I will move our 420-person community when 120 members commit, archive import is verified, three moderators accept stewardship, and a two-week trial reaches the agreed reliability threshold.” ### Assurance flow 1. A captain defines a bounded cohort and proposed conditions. 2. People join privately through invitations; OURS does not scrape contacts. 3. The cell publishes a testable build and migration rehearsal. 4. Independent evidence verifies each required condition. 5. The commitment threshold is reached. 6. OURS announces a scheduled switch window. 7. Migration concierge, import and onboarding help the group land together. 8. Retention and operating health are measured after the switch. 9. Eligible participants become members under the cell constitution. If the conditions are not reached, the pledge expires without shame or artificial urgency. The cell publishes what was learned. ### Portability and the social graph Technical portability is an important rail, but it is not collective migration. Protocols such as AT Protocol demonstrate portable identity and account migration; OURS adds synchronized human intent, assurance and governance. See [AT Protocol identity](https://atproto.com/guides/identity) and [account migration](https://atproto.com/guides/account-migration). Imports and bridges should use official exports, APIs and open protocols. OURS should not base its strategy on violating an incumbent's terms, covert scraping or holding user credentials. ### Defensible value The scarce asset is not source code. It is: - the graph of conditional commitments; - trustworthy adoption and contribution receipts; - proven migration playbooks; - steward reputation; - a history of fulfilled thresholds; - the institution capable of repeatedly mobilizing cells. --- ## 6. Cell lifecycle ### Adopted stages | Stage | Meaning | Required evidence to advance | |---|---|---| | **Signal** | Repeated pain or desire is visible | Named constituency and evidence beyond social reactions | | **Forming** | The institution is being defined | Mission, thesis, constitution draft, initial stewards and migration unit | | **Building** | Executable proposals are being tested | Public build log, tests, cost truth and named owners for work | | **Usable** | Real people repeatedly complete the core task | Reliability and repeated use, not a polished demonstration | | **Ready** | Product and institution can receive a cohort | Product, migration, economics, safety and stewardship gates pass | | **Switching** | A threshold has activated a scheduled group migration | Bounded cohort, switch plan, support coverage and rollback path | | **OURS** | The product operates as a member institution | Legal membership, sustainable operation, transparent governance and retention | | **Dormant / Returned** | The thesis failed or the cell cannot operate responsibly | Assets, code and learning are preserved or returned under the constitution | Stage changes are public events with receipts. Stewards must not advance a cell because of narrative momentum alone. ### Build log Every cell maintains a daily or event-based public log: - what changed; - which hypothesis it tests; - who is responsible; - how to try it; - what evidence would count; - what it cost; - what failed; - what decision follows. The build log should show product progress without turning implementation activity into proof of value. Shipping code is evidence of effort, not evidence that a cell deserves to exist. --- ## 7. Participation, evangelism and ownership ### Participation ladder | Role | Action | Rights and responsibilities | |---|---|---| | **Watcher** | Follows cells and daily events | Public access; no governance power | | **Tester** | Completes real product tasks and reports evidence | Contribution receipts; product feedback | | **Committer** | Makes a conditional switch pledge | Pledge rights, withdrawal terms and migration updates | | **Captain** | Assembles and supports a bounded cohort | Attribution, cohort duty and anti-spam responsibility | | **Contributor** | Supplies work, knowledge, capital or infrastructure | Receipt, agreed compensation or contribution credit | | **Member** | Accepts the cell constitution and member obligations | Legal ownership, vote, surplus and exit rights | | **Steward** | Holds a named operational mandate | Decision authority, review and compensation | Participation should be legible: people must know whether they are watching, testing, committed, contributing, governing or operating. ### Contribution receipts A contribution receipt should record: - contributor identity or approved pseudonym; - cell; - contribution type; - time and scope; - evidence or linked outcome; - verifier; - attribution lineage; - compensation status; - retention milestone when adoption is involved; - disputes or reversals. Receipts provide memory and accountability. They are not tradeable assets. ### Evangelism policy The system must remember who created real adoption without allowing popularity to buy control. Adopted guardrails: - No reward for impressions, likes, clicks or raw sign-ups. - Adoption credit activates only after real use and defined retention milestones, such as 30 or 90 days. - Direct attribution only; no referrals of referrals. - No multilevel incentives. - Contribution credits are non-transferable. - Spam, purchased traffic and misrepresentation void attribution. - A person cannot accumulate extra governance votes through promotion. Evangelism may create: - a permanent public contribution receipt; - eligibility for cell membership after genuine participation; - eligibility for paid captain or steward work; - participation in a capped annual contribution pool after costs and reserves. > **Evangelism can earn economics, never extra sovereignty.** The precise economic treatment is a **future legal decision**. It must avoid creating an unlicensed security, misleading promise of future value or incentive to recruit regardless of product fit. ### What co-ownership must mean “Co-owner” is not a badge or point total. Depending on the jurisdiction and final entity structure, it should include: - a legally recognized membership interest; - a constitutional vote; - participation in surplus under transparent rules; - rights over major asset sales, data policy, advertising, merger and shutdown; - access to operating and governance records; - data portability; - a defined exit and dissolution policy. The cooperative principle of democratic member control provides a useful foundation, usually one member and one vote. See the [International Cooperative Alliance principles](https://ica.coop/en/cooperatives/cooperative-identity). Until a legal structure and membership interest exist, use “committed to member ownership,” not “member-owned.” --- ## 8. Governance: constitutional democracy, operational leadership Collective ownership must not become product-by-referendum. ### Member-reserved decisions Members govern: - the mission and constitution; - membership classes and rights; - data and advertising rules; - material changes to surplus allocation; - major capital, merger or sale; - shutdown and disposition of assets; - election or ratification of stewards where defined. ### Steward decisions Paid, accountable stewards decide: - daily roadmap and sequencing; - interface and implementation choices; - staffing and vendors within the approved budget; - experiment design; - incident response; - routine pricing and operations within constitutional boundaries. ### Expert authority Qualified experts can hold narrowly defined and reviewable safety, regulatory, security or financial-control vetoes. Expertise must not become an unlimited governing class, but a popularity vote must not override a concrete safety obligation. ### Founder mandate The founder does not need to surrender authorship or operating clarity to prove collective intent. The initial constitution should establish a clear, time-bounded founder or chief-steward mandate—**hypothesis: 18–24 months**—with scope, compensation, review and succession rules. ### Agents AI agents may propose, build, test, summarize and operate within explicit mandates. They cannot become members, vote, ratify ownership changes or silently write canonical governance records. --- ## 9. Cell and federation architecture ### One passport, many memberships People have one portable OURS identity and contribution history, but ownership and voting are cell-specific. Supporting one cell must not silently grant power over another. ### OURS Commons The shared federation layer should maintain: - the public Mission Market; - identity and verified participation primitives; - constitutional minimums; - contribution and decision receipts; - Together Pledge and migration tooling; - safety and integrity standards; - shared hosting, payment and observability options; - legal and operational templates; - interoperability and export formats; - the OURS brand and protocol. ### Product cells Each cell controls: - its mission and thesis; - membership and stewards; - product assets, domain and brand extensions; - contracts and operating account; - cell data policy; - product roadmap; - costs, revenue, reserves and surplus; - migration and shutdown plans. ### Practical legal sequence **Hypothesis:** begin with one umbrella multi-stakeholder entity and separately auditable cell ledgers. Do not create a new legal entity for every early experiment. Mature cells can become independent cooperatives or appropriate member entities and federate back into OURS. The exact structure depends on jurisdiction, tax, securities, cooperative and employment law. Platform cooperatives can align stakeholders, but financing, scaling and federation require deliberate design; the [OECD platform cooperative review](https://www.oecd.org/content/dam/oecd/en/publications/reports/2023/09/empowering-communities-with-platform-cooperatives_63d716b6/c2ddfc9f-en.pdf) is a useful reference. ### Right to leave Every cell must be able to export and leave with: - its constitution and decisions; - member records subject to individual consent; - contribution ledger; - product and operational data in documented formats; - code and licenses according to the cell constitution; - a clear settlement of shared liabilities. Without a right to leave, OURS would eventually become another platform landlord. --- ## 10. Economics ### Adopted principles - No behavioural advertising. - No sale of member or behavioural data. - Transparent product price or membership fee. - Costs, reserves and surplus visible to members. - Free public watching and low-friction trials are acceptable; durable use must pay for durable operation. - Hosting, support, moderation, safety, payments, legal work and stewardship are real costs even when software creation is cheap. ### Cell economics A cell should publish: - revenue by source; - recurring infrastructure cost; - payment and marketplace fees; - safety, support and moderation cost; - steward compensation; - legal and compliance cost; - required reserve; - available surplus; - federation contribution. ### Federation economics **Hypothesis:** mature cells contribute 5–8% of revenue, or a transparent cost-based equivalent, to shared federation services. The pilot must reveal whether a revenue percentage, per-member charge or service menu is fairer. ### Capital Possible instruments, subject to licensed advice: - preorders and assurance contracts; - nominal membership shares; - member loans; - capped, non-governing outside capital; - grants for public-interest infrastructure; - revenue financing with explicit limits. OURS should not promise speculative appreciation or disguise an investment product as contribution credit. --- ## 11. Which products deserve cells The protocol can be broadly applicable, but the Mission Market should not admit every idea. Strong candidates have most of these properties: 1. Users create essential network, data, supply, content or trust. 2. Coordination is the primary switching barrier. 3. A bounded cohort can migrate together. 4. The incumbent misalignment is specific and observable. 5. Member-aligned revenue can cover real operation. 6. Portability is technically and legally plausible. 7. Safety and moderation obligations can be met. 8. The cell can define what success and failure mean. Likely strong categories: - communities and social groups; - creator and audience networks; - marketplaces with interdependent supply and demand; - knowledge commons; - family or member-generated data services; - local services where participants create the system's value. Likely weak categories: - commodity utilities with negligible network effects; - products whose only thesis is “the same thing, but ours”; - cells requiring mass scale before creating any value; - missions with no plausible operator or economic loop; - unsafe or regulated services whose requirements are being treated as future details. --- ## 12. Cell 001: Community Home ### Why this should be first Do not begin with a social network for children. That remains an important north-star mission, but it carries unusually high safety, moderation, age-assurance, privacy and regulatory obligations. In Europe, services accessible to children have heightened safety and privacy duties, restrictions around profiling-based advertising, and member-state variation in parental-consent thresholds. See the European Commission guidance on [children and digital services](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/rights-child/digital-and-information-society_en) and [GDPR safeguards for children](https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/legal-grounds-processing-data/are-there-any-specific-safeguards-data-about-children_en). The first cell should prove the coordination thesis with one bounded adult community of roughly 300–3,000 people. ### Mission > **A community should own its home, relationships and archive.** ### Thesis > **If a majority can make a conditional group pledge and migration is concierge-assisted, an established community can move together in one weekend.** ### Product Reuse mature open-source community software. Build only the missing coordination layer: - Together Pledge; - cohort and captain tools; - import and migration rehearsal; - membership and constitution acceptance; - contribution receipts; - public build and decision log; - switch scheduling; - retention and cost truth. The exact community engine is a **future decision** after the pilot community's actual needs are known. ### Proposed validation gates These numbers are hypotheses, not commitments: - 30% of the source community makes a conditional pledge. - 100 members use the alpha for a real task. - 50 members pay, reserve or otherwise demonstrate economic commitment. - Three non-founder stewards accept named responsibility. - Archive and identity import pass a rehearsal. - A rollback and support plan exists. - At least 60% of migrated members remain active four weeks after the switch. - Operating cost per retained member is visible and coverable. ### Concierge pilot plan #### Days 1–5: Find the migration unit - Recruit three candidate adult communities. - Interview owners, moderators and members separately. - Select one community with visible pain, trusted stewards and exportable data. - Record the incumbent harm and the non-negotiable product requirements. #### Days 6–10: Form the cell - Write the one-page mission, thesis and temporary constitution. - Name the initial stewards and decision boundaries. - Define the Together Pledge and switch threshold. - Publish the first cell page and build log. #### Days 11–20: Prepare the home - Configure the selected open-source product. - Build only the required import, pledge and membership seams. - Rehearse archive, identity and moderator migration. - Expose cost, reliability and missing capabilities. #### Days 21–30: Prove readiness - Run the alpha with real community tasks. - Fix blocking failures. - Verify the threshold independently. - Schedule the switch only if every declared gate passes. #### Days 31–60: Switch and retain - Run the group migration with live support. - Publish migration and incident receipts. - Measure week-one and week-four retained use. - Ratify membership only under the stated legal and constitutional rules. - Publish whether the thesis passed, failed or remains unresolved. ### Pilot success The pilot succeeds when the community moves together, the product remains useful, non-founder stewards operate it, members understand their rights and the economics can cover operation. The pilot fails honestly when the threshold is manufactured, the product works only as a demonstration, the community fragments, one founder performs all stewardship indefinitely or costs cannot be covered. Repeat the motion with five different communities before treating the coordination architecture as proven. --- ## 13. Product roadmap ### Phase 0 — Concierge proof **Goal:** prove that OURS can move one real group. Build only: - one public Mission Market page; - one cell page; - Together Pledge; - captain invitations; - a build and decision log; - manual contribution receipts; - threshold verification; - a switch event page; - basic retention and cost reporting; - complete export. Most operations can be manual. The first product is the coordinated migration, not the software platform. ### Phase 1 — Repeatable movement **Goal:** move five communities using the same primitives. Add only after repeated demand: - reusable cell templates; - role and steward management; - cohort privacy controls; - automated receipts; - migration rehearsal tools; - cell health dimensions; - federation service accounting. ### Phase 2 — Mission Market **Goal:** let credible missions form and progress without direct founder orchestration. Add: - cell admission workflow; - structured mission and thesis records; - public readiness dimensions; - daily OURS TODAY edition; - discovery fairness; - disputes and evidence review; - reusable governance templates. ### Phase 3 — Federation **Goal:** enable mature cells to become independent institutions while retaining interoperability. Add: - portable identity and membership proofs; - federated cell exports; - shared constitutional minimums; - inter-cell services and settlement; - formal Commons governance; - cell secession and federation procedures. ### Explicitly not in the first release - an AI code editor; - arbitrary public idea submissions; - a token or trading market; - tradable contribution credits; - an infinite social feed; - a native mobile application; - a children's social network; - automatic cooperative incorporation; - complex prediction markets; - generalized polling on product details. --- ## 14. First implementation model ### Core records The early system should be built around a small, explicit event model: - **Person** — identity, consent and cell-specific roles. - **Mission** — enduring outcome and constituency. - **Thesis** — falsifiable proposition and evidence requirements. - **Cell** — stage, constitution, stewards and operating identity. - **Build** — version, experiment and trial instructions. - **Evidence** — observation, method, source and verifier. - **Commitment** — conditional pledge with threshold and expiry. - **Cohort** — bounded group, captain and privacy policy. - **Gate** — declared condition and verification state. - **Switch event** — schedule, support, rollback and outcome. - **Membership** — legal or provisional status, rights and obligations. - **Contribution receipt** — work, adoption or responsibility evidence. - **Decision** — authority, options, result and rationale. - **Ledger snapshot** — cost, revenue, reserve and surplus truth. ### System invariants - A social reaction cannot satisfy a product or migration gate. - A commitment cannot activate without all declared conditions. - A contribution receipt cannot silently alter governance power. - An agent cannot ratify a canonical governance or ownership event. - A stage change requires public evidence. - A cell can export its records in documented formats. - Deleted or withdrawn personal data does not remain usable for growth attribution. - Concept data is visibly distinguished from live evidence. - “Member-owned” is displayed only when the legal state supports it. --- ## 15. Visual direction ### Adopted character OURS TODAY should feel like a live civic instrument rather than a SaaS dashboard or crowdfunding directory. - A large, direct question leads the page. - Dense mission cells form the dominant field. - Hard edges and disciplined typography communicate seriousness. - Color indicates movement and stage; it is not decoration. - Numbers are specific and inspectable. - Cell detail opens directly into action. - Product activity feels live without becoming noisy or compulsive. - The visual hierarchy rewards missions and proof, not personalities. ### Design guardrails - Do not use rounded-card abundance, generic gradients or startup illustration. - Do not create a ticker that resembles securities trading. - Pair color with labels so status is never color-only. - Keep fictional data explicitly marked as concept data. - Support keyboard use, small screens, light and dark appearance, and reduced motion. - Do not let the heatmap become a feedback loop in which visibility alone creates visibility. ### Current proposal The saved [Mission Market design](./mission-market.html) is an interaction and visual-language proposal, not a final product identity. It demonstrates: - the market map; - relative mission momentum; - selected-cell detail; - the next-unlock mechanism; - direct participation actions; - contribution guardrails. --- ## 16. Principal risks and constitutional guardrails | Risk | Guardrail | |---|---| | Popularity is mistaken for viability | Use verified commitments, retained use, cost and readiness dimensions | | Influencers buy power | One member, one vote; adoption credit never changes sovereignty | | Referral spam | Direct attribution, retention milestones, caps and revocation | | Ownership becomes cosmetic | Legal membership, constitutional rights, transparent assets and exit | | Governance paralyzes product work | Members control constitutional matters; stewards control daily execution | | The founder hides permanent control | Time-bounded mandate, disclosed compensation, review and succession | | OURS becomes another landlord | Complete export, cell secession and federated architecture | | Cells become zombie projects | Objective gates, dormant/returned state and visible cost truth | | Code output is mistaken for progress | Builds count only when they produce use or evidence | | Safety becomes a future task | Safety gates and qualified bounded vetoes before readiness | | A token creates speculation or legal exposure | No token, no transferability and licensed review of economic rights | | Incumbent migration depends on prohibited access | Official exports, open protocols, consent and manual fallback | | Early platform work consumes the mission | Concierge one real migration before generalized infrastructure | --- ## 17. Decisions intentionally deferred The following should not be guessed before Cell 001 provides evidence: - jurisdiction and exact cooperative or multi-stakeholder entity; - legal membership classes and nominal share design; - contribution-pool formula and tax treatment; - precise federation fee model; - source-code and content licenses; - identity assurance level; - community software used in the first migration; - final visual identity and typeface licensing; - universal cell admission and appeals process; - long-term Commons board composition; - requirements for a future children's social cell. --- ## 18. Immediate next actions 1. Register `ourstoday.com` and, if pricing is reasonable, `ours.biz`; enable renewal protection, registrar lock and strong account security. 2. Commission trademark/category-confusion screening before a broad public launch. 3. Initialize the repository and treat this document as the decision baseline. 4. Turn the saved Mission Market proposal into a minimal public shell without building accounts or infrastructure prematurely. 5. Recruit three candidate adult communities and select the first bounded migration unit. 6. Write the Cell 001 temporary constitution and Together Pledge with the selected community. 7. Run the concierge pilot and publish the outcome whether it succeeds or fails. 8. Build generalized software only after the same manual step becomes a repeated bottleneck. --- ## 19. North-star state OURS succeeds when people stop saying: > “Someone should build an alternative.” And instead see: > **72% ready. The product works. The switch is Saturday. This cell belongs to its members.** OURS is not another place to generate software. It is an institution for moving society from products people merely use to products they can collectively govern.