# KenMatch: competitor and collaborator intelligence

**Research cutoff: September 23, 2026**  
**Assessment type:** source-grounded strategic analysis; public evidence, code and prototype audit  
**Reading order:** executive synthesis → canonical architecture → strongest analogues → strategy → source and ecosystem audits. The companion workbook contains the full comparison fields, entity census and every original ecosystem-map row.

## 1. Executive synthesis

**KenMatch is best understood as a proposed public institution for choosing, funding, executing and evaluating sustained AI work. Its current product is a public coordination prototype with database credits and sandbox execution.** Treating it simply as a freelance marketplace, prediction market, DAO, AI-agent marketplace or grant site hides the most important comparisons. Conversely, treating its complete vision as already operational would materially overstate its position. The repository explicitly separates operational account/community functions, sandbox allocation/funding/run records, and unconfigured provider execution. [KenMatch product-state declarations](https://github.com/lowestprime/kenmatch/blob/fc3c8b55d7aa9467705c21633811f5f7653cf883/src/lib/product-truth.ts), [live FAQ](https://kmat.ch/faq).

The defining proposed chain is:

**Community identifies a problem → participants refine a bounded proposal → legitimate, nonpurchasable influence prioritizes it → pooled resources fund constrained AI execution → reviewers assess artifacts and outcomes → contribution and demonstrated value inform future rights or benefits.**

That interpretation survives comparison with the supplied Markdown and current product, with an important qualification: the final execution, outcome-validation and reward-feedback loop is an ambition, not demonstrated production operation. The document also contains mutually inconsistent drafts, including blockchain, decentralized hardware, financial-rights and autonomous-routing claims. Those do not override the current implementation.

### The most consequential findings

1. **The strongest existing workflow analogues are Deep Funding/Deep Projects and Project Catalyst.** They combine proposals, community review/selection, funding, team execution and milestone evidence. They should receive more attention than generic agent marketplaces. They do not establish KenMatch’s specific combination of contribution-based nonpurchasable voice and pooled long-horizon frontier-agent allocation. [Deep Projects rules](https://deep-projects.ai/rules/), [Catalyst process](https://docs.projectcatalyst.io/).
2. **Colony, Sensorica and DisCO are especially important for contribution, authority and benefit distribution.** These comparisons expose a weakness in the KenMatch narrative: “rewarding value” is not a new mechanism by itself, and the hard part is defining who may validate which contributions and how that affects power. [Colony reputation](https://docs.colony.io/learn/governance/reputation/), [Sensorica contribution accounting example](https://www.sensorica.co/products/iop-collaboration), [DisCO governance model](https://beta.disco.coop/governance-model/).
3. **AI Horde is the clearest practical earned-compute-priority comparison.** ResearchHub adds a substantial open-research, contribution-reward and funding loop. BIO/VitaDAO add community scientific funding and economic rights. Each reproduces important portions of the architecture; none should be dismissed as merely thematic. [AI Horde mission](https://aihorde.net/mission/), [ResearchHub description](https://docs.researchhub.com/welcome/what-is-researchhub), [BIO](https://www.bio.xyz/), [VitaDAO research](https://www.vitadao.com/research).
4. **The closest broad proposals include 100X, FoundUPS and One People.** 100X connects community-selected ideas, compute pools, agent builds, review and revenue distribution, but explicitly gives capital/staking a governance role. One People describes contribution recognition and community-funded commons jobs, while explicitly saying its proposed nonprofit/cooperative institutions are not operating. FoundUPS combines agent work, compute allocation and proposed benefit economics, with code and simulation that do not prove full production integration. These are serious comparisons at the design level, not verified identical businesses. [100X governance](https://protocol.100xlab.ai/docs/governance), [One People proposal](https://onepeople.cloud/vision/op-coin/), [FoundUPS repository](https://github.com/FOUNDUPS/Foundups-Agent).
5. **No completely or essentially identical operating implementation was established by the evidence inspected.** This is a bounded negative finding, not proof of worldwide uniqueness, patent novelty, or an uncontested market. Several projects substantially overlap with KenMatch’s vision, and a composed stack of existing tools could reproduce much of it.
6. **The strongest collaboration opportunities are functional:** Public AI Inference Utility for public-interest inference; CIP/Weval for community-informed evaluation; Metagov and RadicalxChange for governance design; OpenMined for governed private-data computation; Hypercerts for portable work/evidence records; and selected scientific or open-source communities for independent acceptance testing. None is an announced KenMatch partner. [Public AI identity](https://publicai.co/about), [CIP](https://www.cip.org/), [Metagov](https://metagov.org/), [RadicalxChange](https://www.radicalxchange.org/), [OpenMined](https://openmined.org/), [Hypercerts](https://hypercerts.org/about).

**Strategic judgment:** KenMatch’s opportunity is an unusually coherent combination of public decision rights, sponsor-independent ranking, accountable execution and a reusable public evidence trail. Its main competitive risk is that the combination can be assembled elsewhere before KenMatch demonstrates reliable delivery. Its plausible defensibility is accumulated institutional trust and verified outcomes, not the existence of quadratic voting, credits, a public board or an AI-agent interface.

## 2. Continuity, evidence and confidence

### What was actually recovered

The original private task was retrieved through the task-reading interface. It exposed the original request and attachment references, but no substantive assistant analysis. The shared snapshot was independently opened in a browser and showed the original request followed by a usage-limit message. No unseen prior findings have been invented. The continuity hypothesis supplied in the handoff was preserved and tested.

The large Markdown itself contains earlier candidate lists and analytical drafts. Those were retained as leads: BOINC, Folding@home, World Community Grid, AI Horde, Akash, io.net, Aethir, Gensyn, Bittensor, Gitcoin, research-access programs and agent ecosystems. They were not treated as verified conclusions merely because an earlier generated passage called its research exhaustive.

The interrupted local checkpoint was also preserved. Its JSON evidence archives parsed successfully; the original source hashes remained unchanged; the KenMatch checkout remained clean at the same commit; and `map_specs.tsv` contained all 91 expected entity occurrences, with no missing, extra or malformed rows.

### Evidence labels used throughout

| Label | What it establishes | What it does not establish |
|---|---|---|
| **Observed public presentation** | A page, disclosed state or accessible record was present during inspection | A successful transaction, authentic commercial customer or independently validated result |
| **Source implementation** | A rule or path exists in the inspected repository revision | That the identical revision/configuration is deployed or exercised successfully |
| **Official documented capability** | The responsible organization describes a product or mechanism | Independent performance, adoption, financial accuracy or universal availability |
| **Sandbox/demo** | An illustrative mechanism or seeded record | Real funding, execution, users or impact |
| **Historical** | A dated past mechanism, event or result | Unchanged current operation |
| **Proposal/roadmap** | An intended design | Shipped functionality or a formed institution |
| **Inference** | This assessment’s reasoned comparison or strategic implication | A statement by the organization or an established empirical result |
| **Unresolved** | Evidence is insufficient or identity is ambiguous | Proof that a capability or organization does not exist |

“High confidence” primarily describes a narrow, directly supported finding. It does not certify an entire business. Official pages are strong evidence of published rules and weaker evidence of success. Undated pages are point-in-time observations; their wording is not assumed to have existed throughout earlier periods. Search crawl labels, relative dates and footer years were not used alone to establish launch dates. No claim about post-cutoff events is intentionally included.

## 3. Canonical KenMatch architecture

### 3.1 Current product and proposed institution

The supplied source is an accumulated working dossier, not one clean constitutional specification. The most defensible canonical model gives priority to current implemented rules for current-state claims, and uses the consistent parts of the Markdown for the broader ambition.

| Dimension | Current evidence | Proposed full system / unresolved boundary |
|---|---|---|
| Participants | Account holders, proposers, contributors, moderators, privileged admins/owner and sponsor intake roles | Sustained participation by independent evaluators, resource providers and beneficiary communities is not demonstrated |
| Problem definition | A “Ken” is a bounded work proposal with public-benefit, evidence, deliverable, risk and run-plan information | Broad problem discovery across scientific, technical, civic and creative domains |
| Ideation/refinement | Submission, discussion, revision and intake-review paths exist | Evidence that deliberation systematically improves selected problems is missing |
| Public signal | Broad pulse and scarce voice are distinct concepts in the product | Their empirical predictive/legitimacy value remains untested |
| Decision rights | Database credits, attestation limits and quadratic vote costs; privileged roles control publication and review decisions | Community legitimacy and constraints on ultimate owner power need institutional arrangements |
| Credit issuance | Initial/replenishment credits plus defined awards for accepted proposals, verification and checkpoints | Broad “proof of value” and accurate-curation rewards are not a demonstrated general causal-value measurement system |
| Allocation | Category-local deterministic rank and tier thresholds | Rank is a priority signal, not a guarantee of available compute or successful execution |
| Funding | Treasury, commitments, restrictions and revenue streams are modeled; visible figures are sandboxed | Real unrestricted operating support and sponsor-independent allocation must be proven |
| Provisioning | No configured general public provider-execution layer identified | API, dedicated-cluster and decentralized-provider options remain future execution choices |
| Agent execution | Run states, plans and progress records are modeled | Autonomous long-horizon delivery, multi-provider failover and state migration not demonstrated |
| Milestones | Checkpoint, correction, stop and release events are represented | Actual independent reviewers and live artifact acceptance remain required |
| Verification | Identity/participation attestation is separate from artifact/quality review | Neither identity verification nor a digest proves public benefit or scientific validity |
| Rewards | Nontransferable database allocation credits | Cash dividends, equity, IP ownership and general contributor profit shares are not established current rights |
| Ownership/control | Trusted operator with owner/admin authority; source is publicly inspectable | Public source availability does not establish cooperative ownership, public utility status or irrevocable community control |
| Economic model | Public capacity versus founder/platform shares are modeled in seeded streams | No evidence of commercial revenue, margins or a legally adopted distribution covenant |
| Monetization | Support subscriptions, routing, sponsorship, evaluation traces and separate private work are proposed channels | Each needs demand, permission, cost and conflict-of-interest evidence |
| Technology | Next.js/React/TypeScript, libSQL/SQLite, server actions; optional email, abuse-control and payment integrations | No blockchain or decentralized execution should be inferred from old prose |
| Safety/moderation | Reason-coded review, role limits, appeals and high-risk second approval in code/docs | Operational independence, reviewer capacity and resistance to off-application administrator changes remain risks |
| Public outcome | Publicly legible proposal-to-audit workflow is demonstrated as a prototype | Measured improvement in useful public outcomes per dollar/hour is not established |

Primary current-state references: [architecture](https://github.com/lowestprime/kenmatch/blob/fc3c8b55d7aa9467705c21633811f5f7653cf883/docs/architecture.md), [allocation policy](https://github.com/lowestprime/kenmatch/blob/fc3c8b55d7aa9467705c21633811f5f7653cf883/src/lib/allocation-policy.ts), [attestation](https://github.com/lowestprime/kenmatch/blob/fc3c8b55d7aa9467705c21633811f5f7653cf883/src/lib/attestation.ts), [funding and run governance](https://github.com/lowestprime/kenmatch/blob/fc3c8b55d7aa9467705c21633811f5f7653cf883/docs/funding-capacity-and-run-governance.md), [moderation threat model](https://github.com/lowestprime/kenmatch/blob/fc3c8b55d7aa9467705c21633811f5f7653cf883/docs/moderation-threat-model.md). Source-dossier anchors: KenMatch.md lines 105–249, 335–357, 535–631 and 2783–2960.

### 3.2 Allocation is more specific than “democratic compute”

The ranking code charges the square of the number of votes and computes incremental cost from the difference between successive squares. It caps votes per task at six. Eligible tasks need positive votes and must pass stage/safety conditions. Within a category, votes determine order; ties resolve deterministically using creation time, title and ID. The rank thresholds are nested: **1–3 Months; 4–10 Weeks; 11–100 Days**, giving up to 3, 7 and 90 distinct tasks respectively. Reading the prose as 3 + 10 + 100 independent slots would be wrong. [Allocation implementation](https://github.com/lowestprime/kenmatch/blob/fc3c8b55d7aa9467705c21633811f5f7653cf883/src/lib/allocation.ts).

The source also grants a baseline and periodic replenishment. Consequently, “all power is earned solely by proven value” is too strong a description even of the intended current policy. There is a citizenship/access component as well as contribution rewards. Attestation can reduce or pause participation. Nonpurchasability blocks one direct channel of wealth influence; it does not by itself prevent purchased labor, multiple identities, organized voting, reviewer capture or differences in time available to contribute. These are analytical risks, not findings of an actual attack.

### 3.3 Funding, capacity and execution must remain separate

Public rank can remain stable while available capacity changes. The repository distinguishes committed unrestricted compute support from projected, simulated, restricted or safety-reserved resources. Its capacity states affect launch/concurrency decisions, while reviewers retain reasons to pause, redirect, stop or release work. This separation is a substantive design choice: **a vote does not create money, and a funded task does not automatically pass a safety or quality gate.** [Capacity policy](https://github.com/lowestprime/kenmatch/blob/fc3c8b55d7aa9467705c21633811f5f7653cf883/docs/funding-capacity-and-run-governance.md).

The inspected live economics presentation contained a sandbox usable balance of $30,200 and public burn of $97,800/month, producing about 0.3 months of illustrative coverage. The site explicitly labels its financial and sponsor values as simulated. “Live” or “pilot” badges nested inside demo revenue streams must not be interpreted as verified commercial operations. The website’s liveness endpoint returning healthy is also distinct from a modeled critical compute-capacity state. [Live economics](https://kmat.ch/economics), [health endpoint](https://kmat.ch/api/health).

Fifteen Ken detail pages were retrieved, including blocked safety examples. A running rare-disease example includes apparent milestones, corrections and artifacts, but it also expressly discloses simulated execution and outcomes. A blocked clinical-autopilot example illustrates an intended safety boundary; it does not establish a functioning medical review institution. [Rare-Disease Mechanism Atlas](https://kmat.ch/kens/rare-disease-mechanism-atlas), [Clinical Decision Autopilot](https://kmat.ch/kens/clinical-decision-autopilot).

### 3.4 Verification contains several different problems

KenMatch needs to distinguish at least six questions: Is this a unique/eligible participant? Did computation occur? Does the artifact satisfy its specification? Is its factual or scientific content valid? Did the project create useful outcomes? Which participant caused how much of that value?

A blockchain can record a claim. A hash can identify bytes. A trusted execution environment or computation proof may support a bounded execution claim. A test suite can establish specified behavior on tested cases. None alone answers all six questions. This is why compute-verification networks, identity systems, peer-review markets and impact-record systems can be complementary without being interchangeable competitors.

## 4. Contradictions in the KenMatch sources

| Claim or tension | Reconciliation | Consequence for comparison |
|---|---|---|
| Older Markdown says blockchain-tracked decentralized protocol | Current implementation uses database credits; blockchain explicitly outside current scope | Compare present product with coordination software, and vision separately with DAOs/DePIN |
| Highest-ranked tasks are “autonomously forwarded” to frontier resources | Provider execution is declared unconfigured; inspected run records are sandbox examples | Do not credit KenMatch with shipped execution when comparing against working services |
| Rewards imply economic ownership or fractional monetization rights | Current credit policy does not establish cash, equity or IP rights | Colony/DeSci/DisCO may go further on economic distribution, depending on deployment |
| All influence comes from proven contribution | Baseline/replenishment and attestation rules also matter | Compare the actual rights-allocation rule, not a pure meritocracy slogan |
| Sponsor numbers, revenue totals and pilot users look operational | Global and local sandbox disclosures control interpretation | No market share, retention, revenue or product-market-fit conclusion follows |
| “Democratic governance” suggests decentralized final authority | Owner/admin retain material authority, including publication and role assignment | Formal ownership and accountability remain open design work |
| Duration tiers are expressed differently across drafts | Current thresholds and run-plan records are the relevant prototype evidence | Do not compare “months” as a standardized compute quantity |
| Zero-knowledge proofs, state migration, DQN and specific hardware clusters are presented as implemented necessities | No corresponding general deployed mechanism established in audited execution paths | Treat as speculative alternatives or unsupported claims |
| Revenue split examples are presented with constitutional language | Seeded arithmetic does not prove adopted legal restrictions or actual distribution | Evaluate the sustainability/conflict model separately from financial facts |

The document contains several checkable numerical problems. Its 0.34 Wh versus 0.3 Wh comparison is approximately **1.13×**, not 10×. At $0.20/kWh, 700–800 W over 720 hours costs **$100.80–$115.20** for that load, not $160. A PUE of 1.55 implies overhead equal to 55% of IT energy, or about **35.5% of total facility energy**, not 55% of total. These are corrections to arithmetic in the supplied dossier, not replacement estimates of KenMatch’s real costs. Dossier anchors: lines 699–705.

Other economic examples assume arbitrary token throughput, uninterrupted utilization, particular models, enormous clusters or fixed daily loops. Even where multiplication is internally consistent, it does not establish that a given public problem requires that workload or that the resulting output is valuable. Current provider prices were not needed to establish the competitive classification, and stale illustrative prices are not presented here as September 2026 quotations.

Brand-name discussions, domain preferences, trademark conclusions, founder-income aspirations and statements about other companies’ motives are archival context. They are not evidence of competitor identity, existing legal rights, demand, profitability or operational capability. No trademark clearance, corporate-formation opinion or claim about alleged misconduct is adopted from the dossier.

## 5. Taxonomy: what competes with what

| Competitive question | Relevant family | Representative entities | Proper interpretation |
|---|---|---|---|
| Who chooses which AI projects get resources? | Community funding and allocation | Deep Projects, Catalyst, Gitcoin, Gardens | Strong workflow/mechanism overlap |
| Who turns contribution into influence or benefits? | Reputation and cooperative production | Colony, Sensorica, DisCO, SourceCred, Coordinape | Governance/reward architecture, not necessarily AI execution |
| Who provides earned or public compute access? | Reciprocal/public computing | AI Horde, BOINC, Public AI Utility, NAIRR/ACCESS, DeCLAI | Access substitutes and infrastructure; rules differ |
| Who funds and coordinates scientific work? | Open science/DeSci | ResearchHub, BIO, VitaDAO, Molecule, Experiment | Strong domain overlap; financial/IP rights matter |
| Who evaluates and rewards useful AI output? | Decentralized AI incentives | Bittensor, Allora, Gensyn, Morpheus | Task-quality markets/protocols, not necessarily public-benefit governance |
| Who can produce the requested result today? | Research/coding agents and human challenge networks | Elicit, Edison, OpenAI, Anthropic, OpenHands, HeroX, Wazoku, Topcoder | Direct substitutes for an outcome or budget, even without institutional similarity |
| Who supplies deliberation and legitimacy? | Civic participation infrastructure | Polis, Decidim, CONSUL, Loomio, CIP | Complementary decision processes; no automatic funding/execution |
| Who resembles the entire proposed chain? | Emerging compute/agent commons designs | 100X, FoundUPS, One People, Intellect Project, DAIT | High-interest watchlist; deployment and rights require close scrutiny |
| Who supplies a necessary component? | Compute, privacy and evidence infrastructure | Akash, Prime Intellect, Golem, OpenMined, Hypercerts | Procurement/integration dependencies, not automatically competitors |

A single organization may hold multiple roles. Deep Projects can compete for public-interest AI proposals and also co-fund them. An agent vendor can supply execution and compete for users who simply buy the result directly. An infrastructure organization can become a platform competitor if it adds allocation and community governance. Classification is therefore conditional on the user, workflow and resource decision at issue.

For present-day buying decisions, there is no evidence that KenMatch already substitutes for a reliable production execution service. For its proposed institution, the most important competitors are multi-mechanism funding/production systems and possible assembled stacks. These are different comparisons and should remain visible.

## 6. Strongest structural analogues

### 6.1 Deep Funding / Deep Projects: the strongest AI-project funding workflow

The current `deepfunding.ai` address redirects to DEEP Projects. Its rules describe community feedback and selection, grants, recipient responsibility for delivery, and round-specific conditions. The ecosystem includes historical completed rounds and milestone reporting. A reputation/voting-weight project is documented, but an awarded reputation-development contract is not proof that every proposed weighting mechanism governs current decisions. [Program rules](https://deep-projects.ai/rules/), [Reputo project account](https://community.deepfunding.ai/spotlight-on-innovation-reputo-a-deep-funding-success-story/).

**Assessment:** this is a near-direct analogue for the proposal-to-funded-AI-project workflow. The main architectural difference is the allocated object and executor: grants to teams developing AI ecosystem projects versus KenMatch’s proposed shared frontier-agent effort directed at public problems. KenMatch should benchmark proposal quality, reviewer incentives, milestone failure handling and grantee delivery here. A future claim that KenMatch uniquely connects democratic AI funding to execution would need to survive this comparison.

### 6.2 Project Catalyst: community funding with explicit delivery accountability

Catalyst combines community refinement, voting and milestone-based project execution, with incentivized reviewer roles. Fund-specific parameters matter: the inspected Fund15 documentation includes stake-based voting calculations and March 2026 milestones. Older Fund10 reward numbers should not be carried forward as current constants. [Catalyst overview](https://docs.projectcatalyst.io/), [Fund15 parameters](https://docs.projectcatalyst.io/current-fund/fund-basics/fund-parameters).

**Assessment:** Catalyst is a particularly strong counterexample to any claim that a public proposal board with voting, grants, milestones and rewards is novel. KenMatch’s potentially differentiating commitment is separating money from public allocation voice and using the selected budget for accountable AI work. Catalyst is less close on that constitutional choice, but substantially more relevant on delivery governance than most AI-branded comparison lists acknowledge.

### 6.3 Colony: contribution-earned authority is already a developed design space

Colony’s reputation is nontransferable, domain-aware and earned through particular organizational work/payment paths. Reputation does not eliminate tokens or permission structures; governance actions can require both reputation and token stake. It is therefore inaccurate to describe Colony either as simple one-token-one-vote governance or as completely wealth-independent. [Reputation documentation](https://docs.colony.io/learn/governance/reputation/).

**Assessment:** the important similarity is the feedback loop from contribution to authority over future resources. KenMatch needs equally precise answers about decay, newcomer access, domain expertise, reversals and disputes. Its current event-based awards are easier to understand than a general value score, but they do not yet establish that additional influence tracks additional social value. Colony is both a mechanism-level competitor and a useful design reference, without being a public frontier-compute commons.

### 6.4 AI Horde: earned priority is different from collectively chosen priorities

AI Horde connects contributed computing work to priority in a distributed generation service. Its mission describes kudos as noncommercial but giftable. That combination is not identical to KenMatch’s nontransferable account voice. [AI Horde mission](https://aihorde.net/mission/).

**Assessment:** AI Horde most directly challenges the claim that people can access AI resources only by paying cash to a major provider. However, earning faster service for one’s own request is different from earning influence over which common projects receive resources. KenMatch should keep queue priority, voting rights, reviewer reputation and financial compensation as distinct instruments. Collapsing them into one token would conceal rather than solve their different incentive problems.

### 6.5 ResearchHub: science, review, rewards and funding in one system

ResearchHub documents open research discussion, paid review and RSC-based contribution/funding functions. Its funding guide explicitly says proposal review provides context and suggestions rather than determining whether a proposal receives funding. [Funding recipients guide](https://docs.researchhub.com/researchhub/product-features/fund/funding-recipients), [RSC uses](https://www.researchhub.com/researchcoin).

**Assessment:** this is a strong near-direct analogue for KenMatch’s research coordination ambitions, especially where useful human evaluation earns rewards that can support further research. It differs on tradable economic utility, donor/funder choice and the absence of a demonstrated general public frontier-run allocation constitution. It may be more valuable as an evaluator/replication counterpart than as an adversary. KenMatch should not assume that paying for reviews establishes their independence or accuracy; that requires separate evidence.

### 6.6 BIO, VitaDAO and Molecule: scientific execution with economic rights

These are related but distinct. BIO provides an ecosystem/protocol and scientific-agent work; VitaDAO is a specific research community and portfolio; Molecule supplies scientific IP financing infrastructure. Their relationship is not a reason to count them as three unrelated copies of the same business. [BIO AI](https://ai.bio.xyz/), [VitaDAO portfolio](https://www.vitadao.com/research), [Molecule documentation](https://docs.molecule.xyz/).

**Assessment:** this family makes the ownership question unavoidable. If KenMatch’s goal is open public outputs, IP-restricted commercialization may conflict with it. If it intends to distribute economic upside to contributors, DeSci’s rights and governance arrangements become more relevant—but also substantially more complex than issuing database credits. BIO’s agent work increases technical overlap without removing the difference between capital-linked rights and nonpurchasable public voice.

### 6.7 Sensorica and DisCO: close institutional analogues outside AI branding

Sensorica’s concrete collaboration documentation connects planned roles, logged contributions and resource sharing. DisCO explicitly recognizes livelihood, commons and care work in governance/economic models. [Sensorica project accounting](https://www.sensorica.co/products/iop-collaboration), [DisCO principles and value flows](https://elements.disco.coop/DisCO-in-7-Principles-and-11-Values.html).

**Assessment:** both expose categories of contribution that an AI-task platform can overlook: maintaining community health, onboarding, documenting, correcting, coordinating and supporting shared infrastructure. Rewarding only proposal wins or visible artifacts can underpay essential work. Their main difference is operational substrate—human cooperative production and open networks rather than allocated frontier-agent runs. They are strong organizational analogues and plausible methods collaborators, with no assumed readiness or willingness to partner.

### 6.8 Cobudget: much of the public workflow can be built without a new economy

Cobudget supports proposing, discussing, funding and reporting on projects under a group’s chosen money-governance model. Its practice guide includes proposal quality and accountability, not merely a payment button. [Getting started](https://guide.cobudget.com/article/4-getting-started), [funding-round practice](https://cobudget.com/resources/run-a-kick-ass-collaborative-funding-round-in-5-steps).

**Assessment:** this is a useful “minimum sufficient competitor” test. A community could use collaborative budgeting, an agent service and a public artifact repository to address much of the same need. KenMatch must demonstrate that integrated credits, ranking, execution records and review materially improve outcomes enough to justify adopting a new institution. Integration can be valuable without being a defensible invention.

### 6.9 Gitcoin, Gardens, Optimism and Octant: distinguish mechanisms from live programs

These systems should not be treated as one interchangeable public-goods stack. Gitcoin’s quadratic matching, Gardens’ persistent conviction, Optimism’s retrospective rewards and Octant’s yield/participation model create different rights and incentives. Gitcoin announced the sunset of Grants Stack and Grants Lab in May 2025; its June 2026 AI-transition direction is a strategic discussion, not proof of an operating KenMatch equivalent. Optimism’s August 2026 budget update reports Retro Funding’s pause. Octant documents v1’s final allocation window and migration to v2. [Gitcoin sunset](https://gitcoin.co/blog/grants-stack-winds-down--heres-whats-changing-and-what-to-expect), [Gitcoin June 2026 direction](https://gov.gitcoin.co/t/june-2026-gitcoin-reboot-update-funding-what-matters-in-the-age-of-ai/25288), [Optimism budget](https://gov.optimism.io/t/collective-year-4-budget-update-and-year-5-budget-outlook/10796), [Octant migration notice](https://v1.docs.octant.app/).

**Assessment:** public-goods mechanisms supply precedents for preference aggregation, fund distribution and retrospective reward. They do not supply a settled formula for social value. KenMatch should borrow lessons selectively, preserve versioned rules and avoid presenting a paused or sunset program as a ready integration or guaranteed funder.

### 6.10 Bittensor and Allora: evaluated AI work, but a different allocation constitution

Bittensor’s current Dynamic TAO model and Allora’s worker/reputer incentives are more specific than “decentralized AI.” They connect evaluated output and economic rewards, with stake and market mechanisms playing material roles. [Dynamic TAO](https://docs.learnbittensor.org/dynamic-tao/dtao-guide), [Allora consensus and rewards](https://docs.allora.network/learn/consensus-and-rewards).

**Assessment:** they reproduce AI production, evaluation and incentives more directly than civic deliberation products do. But a useful inference on a defined task is not identical to selecting a socially valuable project, and a market price is not interchangeable with democratic legitimacy. They are serious mechanism competitors and possible suppliers. Any integration should name the particular service, evaluator and failure mode rather than rely on the network’s broad claims.

### 6.11 Morpheus and Virtuals: broad agent economies without the same public mandate

Morpheus explicitly organizes incentives around compute, code, capital and community. Virtuals describes agent identity, commercial jobs, capital and coordination through its agent economy. [Morpheus repository](https://github.com/MorpheusAIs/Morpheus), [Virtuals whitepaper](https://whitepaper.virtuals.io/about-virtuals).

**Assessment:** these are important architectural comparators because they go beyond a simple model marketplace. Nevertheless, capital participation, agent commerce and network incentives do not establish a contribution-only public electorate deciding which common problems deserve frontier resources. KenMatch may purchase useful services from such networks while retaining its own selection and acceptance rules. Their broader roadmap language should not be used as proof that every advertised institution already functions.

### 6.12 Public AI Inference Utility and public research allocations

The Public AI Inference Utility describes a nonprofit, open-source project fiscally sponsored by Metagov, with a service launch in 2025 and subsequent 2026 model/infrastructure updates. It is distinct from its sister Public AI Network. NSF’s March 2026 NAIRR update establishes a continuing public research-resource program. [Public AI about](https://publicai.co/about), [Public AI updates](https://publicai.co/), [NSF NAIRR update](https://www.nsf.gov/cise/updates/nairr-2-years-advancing-american-artificial-intelligence).

**Assessment:** these are especially important substitutes for the access problem and collaborators for the execution layer. Public AI may align more closely with KenMatch’s mission than a tokenized compute marketplace does. NAIRR/ACCESS can be stronger solutions for eligible researchers, while not serving as a universal public electorate. KenMatch should establish which users remain underserved after these alternatives, rather than assert that public or subsidized AI access does not exist.

### 6.13 100X: unusually close pipeline, materially different power

100X documents cause-specific idea selection, operator-led agent sprints, review/testing and revenue distribution funded through a reserve/yield model. Its governance explicitly privileges CPT holdings and staking, and it describes its rules as evolving in alpha. Displayed agent, deposit and uptime numbers were not independently verified. [100X build process](https://protocol.100xlab.ai/docs/how-it-works), [governance](https://protocol.100xlab.ai/docs/governance), [revenue model](https://protocol.100xlab.ai/docs/revenue).

**Assessment:** this is one of the closest discovered causal-architecture proposals. It is also a useful boundary case: replacing capital-weighted direction with nonpurchasable voice changes the institution fundamentally, even if the screens and build pipeline look similar. Neither platform’s planned economics should be accepted as a demonstrated perpetual funding engine. This candidate deserves continued monitoring, without inferring deployment from an attractive metrics display.

### 6.14 FoundUPS, One People, DeCLAI, DAIT and Intellect Project

These belong in the assessment because excluding prototypes would create a misleading impression of conceptual white space. They also require unusually careful evidence labeling.

| Candidate | Why it matters | Why identity is not established |
|---|---|---|
| FoundUPS | Agent work, compute direction, output/benefit distribution and venture lifecycle | Repository explicitly distinguishes staged integration and simulation from proven production; rights differ |
| One People | Contribution recognition, collectively chosen commons work and benefit sharing | Future institutions/rules explicitly not operating or adopted; technical assurances remain unverified |
| DeCLAI | Nonmonetary earned inference credits | Research design, not deployed system; no full civic project lifecycle |
| DAIT | Useful-work incentives and proposed community compute governance | Pre-mainnet/devnet framing; token and grant rules differ |
| Intellect Project | Community AI, contribution ledger, rewards and hybrid governance blueprint | Multi-year roadmap and unresolved implementation/legal details |

Sources: [FoundUPS](https://github.com/FOUNDUPS/Foundups-Agent), [One People](https://onepeople.cloud/vision/op-coin/), [DeCLAI status and limitations](https://github.com/creativeheadz/DeCLAI), [DAIT](https://dait.foundation/), [Intellect Project](https://intellectproject.org/).

**Assessment:** there is meaningful conceptual competition. The evidence does not support “nobody else has thought of this.” It also does not support “these are all functioning businesses identical to KenMatch.” In particular, a stated plan for mathematical verification should not be accepted as an operational impact-verification system. DeCLAI’s explicit withdrawal of unsupported projections is a useful example of the evidentiary discipline needed across this category.

### 6.15 Research agents and challenge networks: lower architectural overlap, high substitutability

Elicit, Edison Scientific, Sakana’s AI Scientist and Google’s AI co-scientist address parts of the scientific output workflow with different maturity and access conditions. Coding/research agents can also substitute for some proposed Kens. HeroX, Wazoku/InnoCentive, Topcoder and XPRIZE instead organize sponsor-defined problem solving and evaluation. [Elicit lineage](https://roche.elicit.com/blog/elicit-raises-9-million-and-becomes-a-public-benefit-corporation), [FutureHouse’s 2026 program and Edison access](https://www.futurehouse.org/fellowship/apply), [Sakana’s bounded publication experiment](https://sakana.ai/ai-scientist-first-publication/), [Google research announcement](https://research.google/blog/accelerating-scientific-breakthroughs-with-an-ai-co-scientist/), [HeroX process](https://www.herox.com/how-it-works), [Wazoku organization](https://www.wazoku.com/about-us/).

**Assessment:** a user may prefer an immediate output or a reliable challenge provider over joining collective governance. Therefore, low architectural similarity does not mean low competitive pressure. KenMatch’s best initial users may be groups whose problem is genuinely collective priority-setting and accountable public delivery, not individuals who merely need a report or software patch.

## 7. The explicit near-identity challenge

An essentially identical implementation would need unusually high correspondence on **all material constitutional and operational elements**, not just a shared mission:

1. A public or community proposal/refinement process.
2. Binding influence substantially independent of purchasing power, with an explicit contribution/participation policy.
3. Collective allocation of scarce sustained AI effort across competing public projects.
4. A real funding/provisioning path and demonstrated execution.
5. Checkpoint, correction, safety and release decisions tied to inspectable artifacts.
6. A contribution/outcome feedback loop that governs future rights or benefits.
7. Compatible public-benefit, ownership and control rules.

This test deliberately distinguishes **operating identity**, **design similarity** and **user substitutability**. A missing detail remains unknown; it is not automatically scored as absent. Equally, unknown details cannot establish near-identity.

| Candidate/family | Strongest reproduced segment | Decisive difference or missing evidence | Judgment |
|---|---|---|---|
| Deep Projects | Proposals → community selection → AI grants → milestones | Team grants; no demonstrated same public runtime/earned-voice loop | Near-direct workflow analogue |
| Catalyst | Refinement → vote → funding → proof of achievement | Stake-linked vote; ecosystem project focus | Strong structural analogue |
| Colony | Work → reputation → authority → resources | Token/stake requirements; no public AI-run commons | Governance analogue |
| AI Horde | Contributed work → priority → AI service | Individual queue priority rather than collective project authority | Compute-access analogue |
| ResearchHub | Contribution → review/rewards → research funding | Tradable RSC and donor-driven funding; different runtime model | Research coordination analogue |
| BIO/VitaDAO | Community funding → scientific work → economic rights | Capital/IP rights and domain-specific control | Scientific production analogue |
| Cobudget/DisCO/Sensorica | Collaborative production/funding/value sharing | Different execution substrate; no same demonstrated AI allocation chain | Institutional analogues |
| Bittensor/Allora | AI work → evaluation → rewards | Market/stake/task quality rather than civic project legitimacy | Incentive-market analogues |
| Public AI Utility | Public-interest access to AI | No demonstrated contribution-to-project-allocation constitution | Access substitute/collaborator |
| 100X | Ideas → votes → compute-funded agents → review → revenue | Capital-weighted voice; experimental deployment evidence | High-overlap planned competitor |
| FoundUPS | Directed compute → agent work → benefit economics | Integration/economic proof and governance differences | High-overlap watchlist |
| One People | Contribution → commons proposals → community benefit | Explicitly proposed institutions, not live cooperative | High-overlap conceptual analogue |
| DeCLAI/DAIT/Intellect | Various earned-resource/governance components | Proposal/testnet/roadmap status; incomplete matching constitution | Research/development watchlist |

**Answer:** no inspected source established a currently operating business or platform completely or essentially identical to KenMatch’s proposed full architecture. Several are close enough that a categorical uniqueness claim would be unjustified. KenMatch itself has not demonstrated its full architecture either, so comparing its complete vision against competitors’ shipped features alone would be an unfair asymmetry.

### The assembled-stack counterexample

A credible alternative could combine a participatory proposal tool, a community treasury/grant mechanism, a commercial or public AI backend, milestone review, a public artifact repository and contribution-based rewards. This is an **analytical construction**, not a claim that these vendors already offer a tested integration or compatible legal arrangement.

Its importance is strategic: KenMatch competes partly with organizational assembly. The product must lower coordination cost, preserve neutral rules and improve evidence quality enough that people prefer the integrated system. An integrated public record can differentiate it; integration alone does not establish a durable barrier to replication.

## 8. Collaborators with concrete complementary value

The following priorities are analytical recommendations. They are **not partnerships, expressions of interest, eligibility determinations or instructions to contact anyone**. No outreach occurred.

| Priority / counterpart | Missing KenMatch capability it could address | Concrete, bounded collaboration hypothesis | What must be verified first |
|---|---|---|---|
| Public AI Inference Utility | Mission-aligned inference access | A small public-output pilot with fixed budgets and exportable artifacts | Model/task fit, limits, support, data handling and permission to orchestrate |
| CIP / Weval | Community-informed public-value evaluation | Co-design a rubric and disagreement-preserving evaluation of one category | Evaluator independence, scope, consent and capacity |
| Metagov | Governance accountability | Review credit issuance, role authority, appeals and institutional change rules | Whether an appropriate research team/program is available |
| RadicalxChange | Allocation mechanism design | Compare current QV with alternative participatory allocation under realistic identity assumptions | Research design, not ideological endorsement of one rule |
| OpenMined | Controlled use of sensitive/private data | A segregated evaluation workflow where data owners retain permission control | Actual deployment fit, threat model and data-provider consent |
| Hypercerts | Portable evidence and funding records | Represent a released Ken’s work claim, evidence and independent evaluations in reusable records | Schema fit, privacy, attribution and avoidance of double-counted impact |
| Deep Projects / Catalyst practitioners | Funded-delivery accountability | Adapt milestone acceptance, reviewer calibration and failed-project handling | Current round rules and conflicts between ecosystems |
| ResearchHub reviewers / scientific communities | Independent scientific criticism | A bounded replication or evidence-audit bounty | Reviewer qualifications, conflicts and whether output licenses fit |
| Open-source maintainers | Real user acceptance | A Ken whose acceptance criteria are agreed by maintainers before execution | Maintainer willingness, review bandwidth and no unsolicited PR burden |
| Sensorica / DisCO practitioners | Contribution and care accounting | Test whether credits miss necessary maintenance, coordination and care work | A small comprehensible policy, dispute handling and evaluation burden |
| Cobudget / Loomio practitioners | Deliberation and funding practice | Improve proposal formation before scarce voice is spent | Group participation and facilitation cost |
| Akash / Prime Intellect / other suitable providers | Actual execution capacity | Benchmark one bounded workload with independent acceptance tests | Cost, availability, reproducibility, security and contractual fit |
| NAIRR/ACCESS or relevant institutions | Resource access and domain expertise | Refer eligible proposals or collaborate through a qualified institution | Actual eligibility and resource rules; no presumed public access entitlement |

Evidence for these functional capacities appears in the comparison profiles and workbook. Additional direct references: [OpenMined](https://openmined.org/), [Hypercerts’ explicit limits](https://hypercerts.org/contact), [Loomio](https://www.loomio.com/docs/en/user_manual/overview), [Akash deployment lifecycle](https://akash.network/docs/learn/core-concepts/deployments/), [Prime Intellect compute platform](https://www.primeintellect.ai/blog/compute).

The best partnership is not necessarily the organization with the most similar mission. A collaborator should supply a missing capability, have compatible rights/incentives, and improve a measurable outcome. A think tank may provide valuable criticism while being unable to supply engineering, reviewers or funding. A provider may supply compute while creating a governance conflict. These distinctions should be explicit in any future agreement.

## 9. Historical and intellectual predecessors

| Predecessor / family | Inherited problem or mechanism | Lesson for KenMatch |
|---|---|---|
| Ostrom Workshop and commons governance | Shared-resource rules, monitoring, institutional diversity | Resource governance requires enforceable local rules and legitimacy, not only voting software |
| Participatory budgeting, Decidim and CONSUL | Proposal formation, citizen allocation and implementation accountability | The proposal-to-delivery chain predates AI; learn from process design and participation failures |
| Quadratic voting / RadicalxChange | Expressing preference intensity under credit budgets | Quadratic cost is one rule within a larger identity and rights system |
| BOINC, Folding@home, World Community Grid | Volunteer resource aggregation and scientific work validation | Resource contribution and problem authority can be separated |
| Climate CoLab / MIT CCI | Public proposal contests and collective problem solving | A visible archive is not proof of an active program or sustainable community |
| Sensorica, DisCO, platform cooperativism | Contribution accounting and distributed production benefits | Governance, care work and economic rights require explicit institutional choices |
| Gitcoin and later public-goods funding | Preference aggregation and matching | Sybil resistance, matching-pool power and evolving program rules matter |
| Optimism retrospective funding | Rewarding demonstrated contribution after work | Ex post rewards can complement but cannot automatically finance all ex ante risk |
| Metaculus and prediction markets | Calibrated expectations and outcome resolution | Predictions can improve selection but cannot define social values by themselves |
| SourceCred / Coordinape | Contribution attribution and peer compensation | Activity and popularity are proxies that can diverge from useful outcomes |
| Convergent Research / FROs | Funding neglected, bounded public-good bottlenecks | Execution organization and clear scope can matter as much as democratic selection |

Sources include [Ostrom Workshop](https://ostromworkshop.indiana.edu/), [QV research](https://www.microsoft.com/en-us/research/publication/quadratic-voting-how-mechanism-design-can-radicalize-democracy/), [BOINC Central](https://boinc.berkeley.edu/central/about.php), [Folding@home](https://foldingathome.org/about), [Climate CoLab read-only notice](https://www.climatecolab.org/feedback), [SourceCred](https://sourcecred.io/docs/), [Coordinape](https://docs.coordinape.com/get-started/give), [Convergent Research](https://www.convergentresearch.org/about).

The intellectual contribution KenMatch might make is a particular institutional synthesis and its empirical demonstration. None of these precedents alone defeats that possibility; together they prevent treating every component as an invention.

## 10. White space, differentiation and defensibility

### 10.1 What could be meaningfully differentiated

The strongest proposed combination is a **public work record that joins legitimacy before execution to accountability after execution**, while keeping sponsorship from buying public rank. Its distinguishing elements could include:

- A proposal that names a beneficiary, deliverables, evidence requirements, limits and stop conditions before resources are spent.
- A transparent allocation rule with participation rights that cannot simply be purchased.
- Separate decisions for rank, funding eligibility, launch capacity, safety and output acceptance.
- Provider-independent evidence and correction history, including failed, redirected and partial results.
- Contribution recognition that improves future decisions without becoming tradable control over the commons.
- A public explanation of how money, labor, compute, decision rights and benefits move through the system.

These are **candidate differentiators**, not verified advantages. The current FAQ itself frames defensibility around trusted governance, public evidence, reputation, reproducible artifacts and provider independence rather than an uncopiable ranking trick. [KenMatch FAQ implementation](https://github.com/lowestprime/kenmatch/blob/fc3c8b55d7aa9467705c21633811f5f7653cf883/src/lib/faq.ts).

### 10.2 Where the apparent white space may be misleading

First, a lack of a famous direct competitor may reflect difficult demand, evaluation and funding economics rather than an untouched opportunity. Second, “continuous compute” is not a unit of value. Some tasks benefit from a short carefully scoped run; others need data, experiments or expert labor that more tokens cannot replace. Third, collective voting can add transaction cost when users already know what they want. Fourth, projects closest to the full vision may be early precisely because integrating these mechanisms is hard.

The market should therefore be defined around **underserved collective work**, not all expensive AI use. A promising initial category would have motivated beneficiaries, reusable public outputs, attainable independent validation, manageable risk and enough uncertainty about priorities that collective judgment helps. This is a selection hypothesis, not a demand finding.

### 10.3 Defensibility risks supported by the evidence

| Risk | Evidence or causal basis | What would create a stronger position |
|---|---|---|
| Interface and allocation-rule copying | Public code and well-known voting/funding primitives | Demonstrated governance quality, adoption and interoperable evidence history |
| Bundling by a funding platform | Deep Projects/Catalyst already cover much of proposal-to-delivery | Better AI-run accountability and genuinely distinct participant rights |
| Bundling by an agent/provider platform | Providers already control execution/user workflows | Trusted neutrality across providers and public-benefit selection they cannot credibly reproduce |
| Community cold start | Allocation, review and funding depend on different participant groups | A narrow recurring workflow with dependable reviewers and beneficiaries |
| Incentive gaming | Credits reward measurable events, which may be imperfect proxies | Audited outcomes, reversals, dispute rules and monitoring for concentration |
| Reviewer capture or bottleneck | Human decisions remain necessary for quality and safety | Independent expertise, recusal, adequate compensation and transparent disagreement |
| Sponsor dependence | Real compute and operating costs must be paid | Diversified support and enforceable separation between money and public rank |
| Founder/operator concentration | Owner/admin and single-primary-deployment architecture | Clear institutional succession, independent review and recovery arrangements |
| Revenue/governance conflict | Several proposed monetization channels touch data, routing or private capacity | Explicit allocation boundaries, consent and public reporting |
| Misleading traction | Seeded figures can look commercial despite disclosures | Unambiguous verified live metrics, with sandbox records visibly separate |

Network effects are conditional. More users can add proposals and evaluation knowledge, but can also add noise and moderation load. More compute providers can improve choice, but incompatible models and weak reliability reduce that benefit. A long contribution history can build trust, but can entrench incumbents. The report does not assign a generic “strong network effect” label without these conditions.

## 11. Strategic dependencies and evidence needed next

The immediate strategic bottleneck is proving a complete loop, not adding more abstract mechanism names. The highest-value validation would be a small set of real Kens with independent acceptance criteria, actual spend, named execution systems, public artifacts, documented corrections and final reviewer decisions. The same records should show how participation affected selection and how any credits were awarded.

| Unresolved question | Why it changes the competitive assessment | Minimal primary evidence |
|---|---|---|
| What has actually run? | Distinguishes coordination prototype from execution platform | Provider usage/billing records linked to run IDs and released artifacts, with secrets removed |
| Who benefits and returns? | Distinguishes mission interest from product demand | Consented user interviews, repeated use and beneficiary acceptance |
| What does voice control? | Determines whether nonpurchasability has institutional force | Adopted authority matrix, change rules, override/appeal history |
| Can money influence rank indirectly? | Tests the central constitutional promise | Sponsor restrictions, conflict disclosures and observed allocation behavior |
| How are credits earned, reversed and capped? | Determines capture, newcomer access and incentives | Versioned policy plus award/reversal ledger and concentration analysis |
| What does “verified value” mean by category? | Determines whether rewards track utility | Preregistered acceptance rubrics, independent review and disagreement records |
| Who owns outputs and data? | Determines compatibility with public goods and collaborators | Adopted licenses, consent terms and project-specific IP arrangements |
| What legal institution owns/controls KenMatch? | Determines whether community control survives founder change | Formation and governing records; not inference from a domain or repository |
| Which economic channels work? | Determines sustainability and conflicts | Real invoices, costs, restricted-fund accounting and demand evidence |
| Can the system survive a provider or operator failure? | Determines utility-like reliability | Tested recovery, exportable state and an independently usable artifact trail |
| Are reviewers operationally independent? | Determines credibility of quality and safety decisions | Role assignments, conflicts, recusal and multi-review records |

No new user input is required to understand the present assessment. These are the missing facts that only operational primary records or future experiments can resolve. Public research cannot manufacture them.

## 12. Complete audit of the supplied ecosystem workbook

### 12.1 What the workbook actually contains

The native ZIP/XML was inspected, including cells, styles, sheet metadata, relationships and ancillary parts. There is one visible sheet, `Sheet1`, with serialized cells spanning A1:A102. **Ninety-four cells contain values:** an invitation at A2, two headings, and **91 entity occurrences**. The first group, A4:A76, is unlabeled; “Writing” appears at A78 and “Academic” at A84. The file has one explicit external hyperlink, `http://pol.is`, at A50.

There are no formulas, cell comments, hidden sheets, merged-cell relationships or substantive graph/drawing content in the inspected package. An empty drawing part and a persons metadata part do not create additional organizations or hidden annotations. Blank serialized cells do not add entries. Bold headings provide grouping; the workbook does not encode directed relationships, economic flows or a competitive taxonomy.

**This is a grouped seed list, not a validated relationship map or complete competitor universe.** The invitation to contact CIP is source content, not authorization to send a message. No contact was made.

### 12.2 Identity normalization

- **Duplicate occurrences:** Reboot appears at A58 and A81; the Ostrom Workshop appears at A21 and A92. Removing those repeated identities yields **89 provisional labels**, not 89 independently verified organizations.
- **Compound entries:** A52 combines Ought/Elicit; A88 combines MIT Connection Science/Constructive Communication. Preserve each source row and normalize its constituent entities separately where useful.
- **Parent/project relationships:** Noema belongs with Berggruen; Ford Public Interest Technology is a program; Climate CoLab is a project associated with MIT CCI; a research center is not its entire university. These relationships should not inflate independent-business counts.
- **Concepts rather than companies:** Exit to Community, platform cooperativism and “Metascience Community” require type labels rather than invented incorporation identities.
- **Geography/institution:** “Ostbelgien” is best treated as a reference to a region’s citizens-dialogue institution, with the original wording retained.
- **Probable names, not certainties:** Moral Imaginations, The Future Society, Linden Lab, Reboot, Newspeak House, Common Wealth and CU Boulder MEDLab have plausible matches, but unsupported certainty is avoided when the workbook provides no URL.
- **Unresolved:** PARPA, Demos’ jurisdiction, the intended Foresight entity and Verses remain qualified. Narwhal can be connected to a CIP founder’s 2023 discussion-platform reference, but its current product/location/status remains unresolved.

The companion `Map Audit` sheet preserves all 91 rows, original text and cells, the original grouping, proposed canonical label, role, identity qualification, evidence URL and retrieval limitation. The original workbook has not been changed.

### 12.3 Important staleness and classification corrections

| Original entry / related ecosystem | Correct treatment | Evidence |
|---|---|---|
| Atlas Computing | Official site is an archive and says work continues at Atlas Ignota; transition date not established by the page | [Atlas team/archive notice](https://atlascomputing.org/team/) |
| Smart Contract Research Forum | GitHub organization archived April 28, 2024; does not by itself prove every legal entity dissolved | [Official GitHub organization](https://github.com/smartcontractresearchforum) |
| Ought / Elicit | Elicit became an independent PBC in 2023; preserve historical lineage | [Elicit announcement](https://roche.elicit.com/blog/elicit-raises-9-million-and-becomes-a-public-benefit-corporation) |
| Unfinished Labs | Former-name relationship to Amplica Labs; not a new unrelated competitor | [SEC-filed record using both names](https://www.sec.gov/Archives/edgar/data/1619394/000167025424000350/document_1.pdf) |
| Open Collective | Platform and other hosts must not be confused with dissolved Open Collective Foundation | [Open Source Collective clarification](https://opencollective.com/opensource/updates/regarding-the-announcement-to-dissolve-open-collective-foundation) |
| Manifold | Sweepstakes closure in 2025 changes cash-out claims; it does not mean the entire platform shut down | [Official announcement](https://news.manifold.markets/p/focusing-on-mana-bringing-sweepstakes) |
| Noema | Publication associated with Berggruen, not another independent governance platform | [Berggruen Institute](https://www.berggruen.org/) |
| Allen Lab | Current institutional name is Democracy Renovation; original shorthand is retained | [Harvard Ash Center](https://ash.harvard.edu/) |
| CU Boulder “Media Lab” | Probable MEDLab match now displays Media Economies Design Lab | [University description](https://www.colorado.edu/lab/medlab/about) |
| Stanford Digital Civil Society Lab | Stanford announced its sunset for June 2025; continuing individual scholarship is distinct | [Stanford notice](https://pacscenter.stanford.edu/news/dcsl-updates/) |
| Civilization Emerging | Retrieved page is Daniel Schmachtenberger’s personal intellectual/publication site, not evidence of a separate operating platform | [Source site](https://civilizationemerging.com/) |
| Narwhal | Historical emerging discussion platform in CIP’s 2023 announcement; not automatically the Canadian news organization | [Founder-authored announcement](https://forum.effectivealtruism.org/posts/suKkvQPxgG6ihvhfP/launching-the-collective-intelligence-project-whitepaper-and) |

### 12.4 Important omissions from the seed map

The supplied map underrepresents operational funding/production mechanisms, distributed compute access, scientific financing and agent execution. High-value additions include Deep Projects, Catalyst, Colony, AI Horde, ResearchHub, BIO, VitaDAO, Molecule, Sensorica, Cobudget, Gardens, SourceCred, Coordinape, Hypercerts, Gov4Git, Decidim, CONSUL, Public AI Inference Utility, public research-compute programs, BOINC, Bittensor, Allora, Morpheus, Virtuals, challenge platforms and scientific agents. The map’s producing organization, CIP, should itself be an explicit node rather than existing only through an invitation.

Not every omission should be added as a “competitor.” A useful replacement map would have typed nodes and edges: **organization → operates product; funder → funds program; community → governs resource; evaluator → reviews artifact; provider → supplies compute; contributor → earns specified right; project → produces outcome.** Unverified relationships should remain absent or explicitly proposed.

## 13. Research breadth, stopping rule and rejected leads

Discovery proceeded from the existing dossier and workbook through governance, public-goods allocation, cooperative production, public/volunteer compute, DeSci, challenge markets, forecasting, agent systems, privacy/evidence infrastructure and high-overlap emerging designs. Searches then challenged the emerging model using combinations such as nontransferable compute credits, community-directed AI builds, contribution-based governance and publicly governed agentic compute.

Those adversarial passes materially expanded the universe: Catalyst, Public AI Utility, DeCLAI, Humanode, 100X, One People and additional agent economies warranted inclusion. Later passes predominantly returned already represented mechanisms, capital-based agent/compute markets, speculative whitepapers or weakly related uses of the same words. No additional verified operating candidate displaced the strongest full-workflow comparisons.

This is a **defensible practical saturation point for this bounded assessment**, not mathematical exhaustion of every organization or repository on the internet. Discovery and verification depth are not the same: a candidate can be fully accounted for as a low-confidence proposal without its claims being verified. Weak leads were retained in the research trail when useful, but were not promoted to major competitors to inflate the census.

Examples of exclusion or qualification:

- Branding collisions such as “Disco” learning software versus DisCO cooperatives, or “Verses” versus VERSES AI, are not silently merged.
- Generic DAO or GPU-token marketing without credible public-problem selection and delivery evidence is not treated as near-identity.
- Autonomous agents voting among themselves do not automatically give human communities legitimate decision rights.
- Research simulators of agent marketplaces do not establish an operating marketplace business.
- Broad advocacy, magazines, university groups and philosophical communities remain ecosystem or intellectual entries unless a specific complementary capability is supported.
- Broken pages, client-rendered shells and crawler refusals are retrieval limitations, not evidence of shutdown.
- Current website counters, token prices, funding totals and performance superlatives were not adopted as independently established facts.

The census distinguishes source-map occurrence counts, normalized labels, products, programs, organizations and grouped comparison families. It does not claim that every row is a separate company.

## 14. Final contradiction, omission and provenance audit

| Audit | Result |
|---|---|
| Prior-thread continuity | Only visible content used; no imaginary prior draft or rejected-candidate history |
| Input identity | Both supplied files hashed; local/Library Markdown copies matched; originals unchanged |
| Full workbook accounting | All 94 populated cells and all 91 entity occurrences accounted for; duplicates and structural limits recorded |
| Repository identity | Correct local checkout and GitHub repository; immutable revision recorded; no source edits |
| Current vs proposed KenMatch | Explicitly separated across architecture, matrix, profiles and conclusion |
| Live vs code | Public pages observed; authenticated mutations/provider transactions not claimed tested |
| Sandbox vs traction | Financial, run, user and output examples not counted as commercial evidence |
| Near-identity | Strong candidates challenged on rights, resource allocation, execution, verification and maturity |
| Duplicate brands/parents | Relationships retained; grouped comparisons not counted as independent businesses |
| Staleness | Gitcoin, Octant, Optimism, Gensyn, SCRF, Atlas, Manifold, Ocean, Open Collective Foundation, Stanford DCSL and Climate CoLab qualified |
| Collaborator validity | Each recommended counterpart linked to a missing function, not only a shared theme |
| Mechanism omissions | Civic, cooperative, grant, science, forecasting, challenge, agent, compute and evidence families included |
| Fact vs inference | Strategic rankings, network effects, moats and collaboration hypotheses labeled analytical |
| Source provenance | Claim-linked URLs, source-file hashes, source cells, code revision and retrieval status retained |
| Residual uncertainty | Legal ownership, real execution, financial performance, adoption and several source-map identities remain unresolved |

### Limits that remain material

No private operating records, confidential competitor contracts, actual KenMatch sponsor settlements or independent live-run evaluation records were available. No account creation, paid transaction, voting mutation, funding submission or external outreach was performed. Public visibility of a feature is narrower evidence than end-to-end authenticated testing.

The repository inventory covers all 411 tracked files and their hashes. The substantive implementation audit concentrates on mechanism-bearing code, public routes, seeds, permissions, ranking, funding, moderation, attestation and run records. It is not a claim that every dependency-lock token or binary byte received semantic review, nor a security certification or a new full test-suite run. Public behavior does not independently attest the exact deployed commit. These limits are preserved rather than replaced with an “exhaustive” label.

The supplied Markdown was extracted in full with 3,511 numbered source lines, its embedded logo was inspected, and its major sections—including repeated drafts, economics, branding, references and prior research traces—were evaluated for relevance and contradiction. Embedded historical instructions were treated as data. The complete workbook received native package inspection rather than summary-only treatment.

**Final confidence:** high that the current KenMatch is a coordination prototype with sandbox execution; high that multiple established systems reproduce substantial component workflows; moderate that the identified strongest analogues are the most decision-useful comparators within the researched universe; limited confidence in any global negative claim of uniqueness. The evidence supports a potentially distinctive institutional combination, not a proven unique or defensible operating business.

## Appendix A. Source anchors and reproducibility

| Input | Identity / anchor |
|---|---|
| Supplied Markdown | `KenMatch.md`; byte-identical to recovered `KenMatch(20260923-085122).md`; 330,670 bytes; SHA-256 `ea393732883b8bef59086baeaeb301e1471daaf387a0e72c9ca515b520945235` |
| Supplied workbook | `Copy of CIP Ecosystem Map v0.xlsx`; 7,240 bytes; SHA-256 `c3b32ba1541cbc2653b6155bac0d22debd7e43beb42d68220591b3697e5aa824` |
| Repository | `https://github.com/lowestprime/kenmatch`; revision `fc3c8b55d7aa9467705c21633811f5f7653cf883`; 411 tracked-file inventory |
| Live product | Fourteen initial public routes plus fifteen discovered Ken detail pages retrieved; no authenticated writes |
| Prior private task | `6ab393f5-b590-83e8-93d8-a38ad2905a19`; retrieved preview did not expose substantive assistant findings |
| Shared snapshot | `https://chatgpt.com/share/6ab395f9-9300-83e8-84f0-e7cbf91c1be5`; visible usage-limit ending |

Useful Markdown ranges: 1–100 working tasks; 105–249 core mechanism narrative; 273–333 strong present-tense blockchain/execution draft; 335–377 more conditional architecture; 381–650 long-form rationale; 653–850 speculative technical/economic draft; 856–864 founder context; 888–1324 prior feasibility/competitor material; 1325–2698 naming/domain/trademark archive; 2705–3321 revenue/governance planning; 3322–3510 prior research trace; 3511 embedded logo. The ranges locate evidence; they do not make repeated or internally inconsistent passages authoritative over current code.

The companion data files retain structured comparisons, normalization and retrieval qualifications. The report’s conclusions should be updated when new operating evidence changes the current-state boundary, especially real provider execution, independent acceptance results, adopted ownership rules or revenue records.