IDKMesh is an open research and engineering program building a verification-first coordination framework for distributed human + AI work. Its first reference application is a Git-native Verified Swarm Runner, and this repository is its first self-hosting experiment.
It is intended to become reusable infrastructure, not only one application. That generality is a design target, not a capability already proven at scale.
The framework, research program, community, reference implementation, and self-hosting experiment are different layers of one system. ../ITERATION_MODEL.md defines their shared lifecycle and authority vocabulary.
The first major use case is collaborative software engineering because software gives unusually strong verification tools: tests, compilers, static analysis, reproducible builds, benchmarks, code review, and version control.
IDKMesh is simultaneously:
These are complementary layers, not separate projects.
Reusable semantics and infrastructure for coordinating work:
The repository already contains executable pieces of many of these functions, but they are not all packaged as one production service.
Different projects need different validators, roles, risks, evidence, and integration rules.
Example domains include:
A domain/project layer can define:
Independent projects should eventually be able to use the framework without becoming IDKMesh itself.
IDKMesh Core
|
+-- software-engineering project
+-- scientific reproduction project
+-- benchmark-improvement project
+-- knowledge/documentation project
+-- IDKMesh improving IDKMesh
The final item is not merely future intent: this repository already runs bounded self-observation, CI/evolution, IDKGraph, and community-growth experiments against itself.
Current main includes, among other things:
This means IDKMesh is beyond a pure architecture proposal. It does not mean the full reference runner or a distributed production mesh is complete.
A useful conceptual flow is:
uncertain goal
-> competing interpretations / hypotheses
-> bounded WorkUnits
-> matched humans / agents / tools / resources
-> candidate artifacts + worker provenance
-> independent verification and evidence
-> explicit integration / rejection / further questions
-> updated project state
-> next bounded work
The critical trust rule is that stages do not grant themselves the authority of later stages:
worker completion != acceptance
verification recommendation != canonical integration
If IDKMesh were one giant application, contributors would have to agree on that application’s complete product goal before making useful progress.
A framework lets different expertise compose through explicit contracts:
It is not merely:
It may integrate mechanisms from those areas, but the unifying problem is how to convert heterogeneous, imperfect, distributed participation into verified useful work on evolving goals.
The semantic core should know as little as practical about a specific model vendor, agent harness, Git forge, cloud, or domain.
External systems should connect through adapters and protocol mappings. In particular, A2A/MCP are useful interoperability surfaces; IDKMesh should not create another generic transport simply to carry its own WorkUnit semantics.
Project-specific behavior belongs in versioned schemas, policies, adapters, validators, domain/project configurations, and evidence rules.
The implementation is intentionally focused on the software-engineering domain and GitHub-native self-hosting because they offer strong observable verification and provenance.
The immediate task is not to generalize everything. It is to make the current local/interop/evidence path coherent, independently reviewed, reproducible, and useful—then generalize only where observed evidence supports it.
For the current truth and next gates, see:
../README.md;../ARCHITECTURE.md;../schemas/README.md;../ROADMAP.md;README.md for documentation navigation.