IDKMesh — AI agent verification and review-gate auditing

I don't know. You don't know. Together, the mesh can discover, build, verify, and learn.

In plain English: IDKMesh helps teams check AI-assisted work instead of trusting the first answer. A tool that works today, idkmesh gate-audit, reads reviewer approve/reject votes and known correct answers, then reports how often the reviewers fail together and how much independent checking their panel actually provides. It does not run the reviewers or approve changes.

The wider IDKMesh framework explores how people, AI agents, and tools can break goals into small tasks, produce candidate work, verify it separately, preserve evidence, and leave the final integration decision to an authorized human or policy. That automatic end-to-end swarm runner is not yet a finished product. The repository is currently an alpha GitHub-native research and engineering laboratory with runnable tools, schemas, local inspection, and experimental coordination components.

Practical benefit today: Instead of assuming five approvals mean five independent checks, IDKMesh can reveal shared reviewer mistakes, measure the panel's effective votes, and show which seeded known-bad cases passed the gate. You provide recorded verdicts and known correct outcomes; the tool does not collect votes or establish ground truth. Try the working gate audit.

New here? Start by what you want to do:

Your goal	Best first step
Understand the idea without technical background	IDKMesh for Absolute Beginners
Watch sample reviewers make the same mistake, without installing anything	Interactive Reviewer Lab (synthetic browser walkthrough)
Try a real command on included sample votes	Audit a review gate
See why a worker cannot approve its own work	Run the contract demo (synthetic fixtures, no AI)
Inspect recorded attempts and evidence in a browser	Human Control Tower (read-only, local)
Use the approach with a different GitHub project	Project Adoption Guide (manual model; automation incomplete)
Run the local two-attempt loop on committed examples (no live workers)	Local-loop tutorial
Check exactly what is implemented versus planned	Capability Truth Matrix

The boundary to remember: worker says "done" ≠ independently checked ≠ authorized to merge.

A concrete question this repository can already answer: how many independent votes is your review panel actually worth? Often far fewer than the number of reviewers on it. In E017 a 25-verifier panel — every verifier a program, every error an observed missed defect — measured an effective size of 1.00 of 25: under majority vote the panel was worth no more than a single member, while the widely used N/(1+(N-1)rho) correction predicted 1.66. idkmesh gate-audit runs that measurement on verdicts you have already collected, and reports the seeded known-bad candidates your panel let through.

Why would I use IDKMesh?

Your problem	Benefit you can use today	Important boundary
Several AI or human reviewers agree, but may repeat the same mistakes	gate-audit measures errors shared across the panel and estimates effective independent votes	Requires reviewer decisions and known correct answers on an audited set; conclusions are specific to that set
You want to know whether your review gate catches obvious failures	Audit the breach rate on labeled known-bad probe candidates	IDKMesh does not generate probes, run reviewers, or certify that unseen defects will be caught
You need to explain what happened to an AI-produced candidate	Versioned task/result/verification contracts and the local, read-only control-tower help inspect retained claims and evidence	They do not independently establish semantic correctness or authorize acceptance/merge
You want bounded tasks and a safer human/agent handoff	Reuse WorkUnit and evidence contracts in a GitHub-based operating process	Enforcement depends on your deployment; the fully automatic multi-agent runner is incomplete

How it fits existing tools: Keep GitHub, CI checks, your models, and your human reviewers. IDKMesh adds review-gate diagnostics and explicit evidence/authority boundaries; it is not a replacement for those tools. Lower cost, faster delivery, and better real-world correctness are hypotheses to test, not demonstrated general benefits.

For an adoption decision and a worked example, read Getting Started. For command-by-command implementation status, use the Capability Truth Matrix.

Try the contract demo

With Git and Python 3.11 or 3.13, use a virtual environment. Linux/macOS example:

git clone https://github.com/MSKazemi/idkmesh && cd idkmesh
python -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements-phase0.txt
python scripts/demo.py

For Windows, use the environment instructions in CONTRIBUTING.md. No model account or API key is needed. Installation time depends on your environment.

The demo validates committed synthetic fixtures with the real validators and schemas in schemas/ and inputs in examples/. It performs three positive checks and four deliberate rejection checks:

Invalid fixture	Why it is rejected
A task with no security contract	a dispatchable contract must declare its security bounds
A worker result that accepts itself	worker completion is not acceptance
A verifier using the worker's identity	the worker cannot satisfy the independent-verifier contract itself
A verification with mismatched provenance	evidence must bind to the supplied artifacts

No live worker or external verifier is executed. A fixture passing validation is not proof of real-world independence, correct work, or approval to merge. Unexpected process or programming errors fail the demo instead of counting as successful rejection evidence.

Questions and "why is it done this way" belong in Discussions; the issue tracker is for defects and bounded pieces of work. For one concrete task or shared technical responsibility, see the contributor invitation.

The central question

Can a large open community of humans and AI agents discover goals, decompose work, execute bounded tasks, verify results independently, and maintain complex systems better than isolated developers or agents can?

IDKMesh treats that as an empirical question. More agents, more activity, more commits, or more votes are not automatically better.

Current status

For the claim-by-claim source of truth, see the Capability Truth Matrix. Its canonical JSON is validated in normal CI against repository paths and the real CLI command tree, and uses the evidence ladder from planned (0) through production-qualified (5). For the exhaustive code-backed command/API/library inventory, see the Executable Capability Reference; it is CI-checked against the recursive CLI tree, Control Tower discovery, Python client, and idkmesh/ module inventory.

For the commands and interfaces available in code today, use the implementation reference and as-built architecture map. They distinguish init --github --dry-run, local run bookkeeping, checkout-only local-loop execution, and read-only Control Tower HTTP from future network/multi-user and merge capabilities. For common failures see troubleshooting.

Executable research foundation; reference runner still incomplete.

What is already present on main:

• versioned WorkUnit contracts, with work-unit-v0.2.schema.json as the current semantic task contract;
• ResultManifest, EvaluatorPlan, and VerificationResult contracts that separate worker claims, verifier evidence, and integration authority;
• cross-object provenance and integrity validation;
• a five-arm WorkUnit decomposition benchmark contract and strict synthetic-vs-observed evidence boundary;
• protocol-neutral worker-adapter code plus A2A/MCP bindings and SDK/conformance helpers under interop/;
• simulation and experiment code under sim/ and experiments/;
• zero-project-spend compute admission and routing experiments;
• IDKGraph repository modeling, observability, link-integrity, and warning/review machinery;
• GitHub-native ACE community-growth experiments and repository-evolution control tooling;
• durable Product Spine run/create/status/evidence/cancel/list commands, derived WorkUnit/project reads, and an append-only local event stream;
• connector profile validation/import/storage, offline probe/doctor/routing explanation, plus the read-only /api/v1/connections Control Tower surface;
• implementation foundations for Jules, OpenAI-compatible model endpoints, bounded local agents, GitHub ingress/dispatch/candidate observation, and enterprise identity/authorization/audit controls, each with the limitations recorded in the executable capability reference;
• a first installable product surface: pip install . provides the idkmesh CLI, whose gate-audit command packages the measured verifier-panel results (E015/E016/E017) as a review-gate diagnostic;
• protected main with the stable PR gate required on Python 3.11 and 3.13.

What is not yet a finished capability:

• there is no claim that IDKMesh can safely coordinate thousands or millions of real machines;
• the reference Verified Swarm Runner is not yet a polished install-and-run product with multiple production worker adapters;
• canonical real-node integration remains subject to its independent-review/evidence gates rather than being inferred from historical prototypes;
• A2A/MCP support is an interoperability layer, not a claim that every external agent framework is production-integrated;
• autonomous repository/community actuation remains policy- and authority-gated;
• benchmark infrastructure is not scientific proof until controlled observed runs exist.

This distinction is important: implemented infrastructure is evidence of capability to run experiments, not evidence that the research hypotheses are true.

Inspect a swarm run in the Human Control Tower

The local Control Tower is the first system-level GUI for the Verified Swarm Runner. It renders existing Run Evidence Report v0.1 documents as human attention items, attempt-by-attempt claim/evidence layers, authority boundaries, and a semantic background timeline.

git clone https://github.com/MSKazemi/idkmesh
cd idkmesh
pip install .
idkmesh control-tower \
  results/orchestration/replay-fixture-evaluator-plan-good-vs-bad/evidence-report.json

With no path, idkmesh control-tower opens the same committed two-attempt demo. The local API is versioned at /api/v1/, binds only to 127.0.0.1, and is read-only: it cannot execute workers, record a human decision, select a candidate, push Git, or merge. See Control Tower Local API v0.1.

The UI deliberately keeps three different ideas visually separate:

worker claim -> independent evidence -> human authority

This is an inspection surface over existing evidence, not a second source of canonical truth.

For local automation, provide a caller-known ephemeral token without putting it on the command line:

export IDKMESH_CONTROL_TOWER_TOKEN='replace-with-at-least-32-random-characters'
idkmesh control-tower --no-browser --port 8770

# Optional: bound a stalled client, concurrent load and event streams
# (defaults: 10 s, 16, 8; beyond a cap the server answers 503 with Retry-After).
idkmesh control-tower --no-browser --port 8770 \
  --request-timeout 5 --max-concurrent-requests 8 --max-sse-clients 4

curl \
  -H "X-IDKMesh-UI-Token: $IDKMESH_CONTROL_TOWER_TOKEN" \
  http://127.0.0.1:8770/api/v1/status

Python callers can use the dependency-free read-only client instead of hand-coding HTTP:

import os

from idkmesh.api_client import ControlTowerClient

client = ControlTowerClient(
    "http://127.0.0.1:8770",
    os.environ["IDKMESH_CONTROL_TOWER_TOKEN"],
    timeout=5.0,
)

status = client.status()
print(status.request_id, status.value["mode"])

events = client.list_events(limit=50)
print(len(events.value.items))

The client requires an explicit timeout, refuses non-loopback destinations, exposes the server request ID, verifies response content digests, and performs no automatic retries. It covers status, evidence inspection, and the resource-oriented read model (connections, runs, run attempts, retained run evidence, derived WorkUnits and projects, events, and a bounded stream_events reader for the Server-Sent Events stream); see the Python client section of the API specification. The client is read/inspect only: human-decision recording remains unavailable until its authenticated mutation contract is implemented.

Machine-readable discovery is available at /api/v1/openapi.json, and successful inspection snapshots are frozen by control-tower-snapshot-v0.1.schema.json. See the Control Tower Local API v0.1 for media types, deterministic digests, error codes, and authority guarantees.

Find IDKMesh by the problem you are solving

If you arrived with a specific question rather than the project name, use the AI agent verification, orchestration, and trust topic hub. It connects common questions about AI agent verification, multi-agent orchestration, AI code review, LLM-as-a-judge reliability, verifier panels, agent governance, AI provenance, MCP/A2A interoperability, verification scaling, and verified swarm engineering to the canonical contracts, experiments, and implementation in this repository.

If you already know the question you want to ask, browse the 100-question answer map. It is generated from the actual question headings in those ten substantial guides, so it improves navigation without creating one thin page per query.

Try it in five minutes: audit a review gate

The first installable tool cut from this research is idkmesh gate-audit. It measures what a panel of reviewers/verifiers is actually worth: effective independent votes (not nominal head-count), error-correlation structure, and the breach rate of seeded known-bad probe candidates.

git clone https://github.com/MSKazemi/idkmesh
cd idkmesh
pip install .
idkmesh gate-audit examples/gate-audit/panel-votes.example.json --pretty

Prefer a visual interface? The same install includes a local browser GUI:

idkmesh gate-audit-ui examples/gate-audit/panel-votes.example.json

It binds only to 127.0.0.1, uses the same audit engine as the CLI, and adds no runtime dependency. Your verdict matrix is sent only between your browser and the local Python process; IDKMesh does not upload it to a hosted service.

The bundled example is synthetic (its votes come from no real panel, and the file is marked "evidence_class": "synthetic"): on it, a five-verifier panel is worth about 1.69 effective independent votes, while the popular N/(1+(N-1)ρ) heuristic predicts 3.66. The same direction has been measured, not just illustrated: on E017's 25-verifier panel of programs, where every error is an observed missed defect, the effective size was 1.00 against a heuristic 1.66 (E017), and in E015's simulations the heuristic is optimistic for accurate verifiers with modest shared dependence (it is conservative for weak verifiers). These findings hold for the panels and dependence models tested and are not a universal law: concurrent work on a nine-judge LLM panel (Kohli, 2026) reports the heuristic closely matching an eigenvalue-based estimate. Measure your own panel rather than sizing it with the heuristic. The contract is specified in docs/specifications/GATE_AUDIT_V0_1.md. Add --bootstrap for a deterministic finite-sample confidence interval on those panel metrics (issue #520; documented in the same specification's "Finite-sample uncertainty" section). The audit is diagnostic only: it consumes verdicts you collected and grants no acceptance or merge authority. In CI, the same audit runs as a GitHub Action:

- uses: MSKazemi/idkmesh/actions/gate-audit@main
  with:
    votes-file: path/to/panel-votes.json

For a complete least-privilege workflow_dispatch example that pins both the checkout step and IDKMesh to reviewed commit SHAs, copy examples/gate-audit/github-action-workflow.example.yml. It is intentionally opt-in: point it at verdicts your repository already collects rather than manufacturing review data for the demo.

idkmesh itself stays dependency-free (pip install . pulls in nothing beyond the standard library). Real, schema-based independent verification of ResultManifest/VerificationResult documents (experiments/local_verifier.py) needs the optional jsonschema dependency; install it explicitly with pip install -e '.[verify]' when you need that capability. See docs/decisions/ADR-0012-optional-verification-dependency.md.

Use IDKMesh to develop another project

If your goal is not to contribute to IDKMesh itself, but to use the framework while building a different application, start with the Project Adoption Guide.

It walks from an empty directory and new GitHub repository through project policy, bounded Work Units, human/agent/model connection patterns, capability/risk routing, candidate branches, independent verification, protected integration, and outcome feedback.

Current boundary: this is usable today as a GitHub-native operating model plus contracts and validation components. The polished one-command external-project bootstrap and fully automated Verified Swarm Runner are still being built.

Start here

You do not need to understand the entire repository before contributing.

1. Read this README.
2. Read CONTRIBUTING.md.
3. Pick a live task from the Contributor Quickstart. Working with an AI coding agent (Claude Code, Codex, Jules)? Start with the agent contributor guide.
4. Browse the live good first issue and help wanted views.
5. Before starting, check assignees, recent comments, and linked pull requests, then state the bounded change you intend to make.

Current newcomer-sized examples (open on GitHub when checked on 2026-10-14; re-check before starting):

• #542 — walk the newcomer path and record where it breaks, no code required;
• #403 — first-run report: what confused you?, no code required;
• #401 — install gate-audit and report setup/test results, especially useful on external platforms.

For bounded code, test, documentation, and research tasks that are not yet filed as issues, see the Starter task catalog.

The ACE Bootstrap Cohort Observatory is the live evidence source for the original growth-seed cohort. It intentionally distinguishes activity from verified external participation.

If something is confusing, stale, contradictory, or difficult to discover, reporting or fixing that is useful project work.

IDKMesh in 60 seconds

• IDK means I Don't Know: uncertainty, disagreement, assumptions, and competing hypotheses are first-class states.
• Mesh means a network of people, agents, tools, evidence, tasks, and compute rather than one monolithic agent.
• Workers should receive bounded Work Units, not unlimited project authority.
• Worker completion is not acceptance; verifier recommendation is not merge authority.
• Verification, provenance, reproducibility, and security must scale with generation volume.
• Diversity matters only when it adds sufficiently independent useful evidence.
• Git/GitHub are the current collaboration and canonical-history substrate.
• A2A and MCP are integration surfaces; IDKMesh should not invent commodity transport protocols unnecessarily.
• The public repository is also project memory: durable decisions, findings, evidence, and important collaboration history should remain inspectable.

Develop with IDKMesh: agent/model connector control plane

IDKMesh is being productized in two deliberate loops:

Loop A — build IDKMesh
GitHub issue
 -> bounded WorkUnit
 -> Jules / OpenHands / local agent
 -> candidate PR/artifacts
 -> independent verification
 -> human integration

Loop B — use IDKMesh
new application specification
 -> GitHub project + IDKMesh profile
 -> backlog + WorkUnits
 -> heterogeneous agents/models
 -> verified candidate PRs
 -> human product decisions
 -> release

The product direction is a Connector Control Plane that separates four replaceable integration layers:

Layer	Initial targets
SCM/project	GitHub
coding agents	Jules REST, GitHub-native agents such as OpenHands, bounded local agents such as goose/Gemini CLI, A2A/MCP workers
model providers	one OpenAI-compatible baseline covering compatible Gemini/Ollama/vLLM/OpenRouter/LiteLLM deployments, with native drivers only when required
execution	hosted agent sandboxes, local Docker/idkmesh-node, appropriate GitHub Actions compute

The coordinator should not contain a separate branch for every model or agent. Every worker still terminates in the same IDKMesh trust path:

configured connection
 -> admitted WorkUnit
 -> untrusted candidate
 -> ResultManifest
 -> independent VerificationResult
 -> evidence/report
 -> explicit human/governance integration

This connector product is under implementation, not a finished public API. Substantial foundations do exist on main: connector profile validation/list/import, offline probe/doctor/routing explanation, durable metadata, the read-only GET /api/v1/connections surface, GitHub dispatch/candidate foundations, and library support for Jules, OpenAI-compatible endpoints, and bounded local agents. Treat each surface according to its documented authority and maturity rather than assuming either "all planned" or "production-ready". The complete code-backed inventory is the Executable Capability Reference.

Current source of truth:

• connector-control-plane architecture;
• Connector Control API v0.1 design;
• implementation + self-hosting plan;
• model-tier dispatcher execution plan;
• live umbrella tracker #570.

The component queue is deliberately bounded; current tracker state is:

1. merged/closed: #574 — connector kernel, profile validation, probes, routing;
2. open: #575 — Jules REST agent connector;
3. open: #576 — OpenAI-compatible model-provider connector;
4. open: #577 — bounded local agent runner;
5. merged/closed: #578 — GitHub issue/webhook dispatch bridge;
6. merged/closed: #579 — canonical candidate/result normalization;
7. open: #580 — CLI and optional HTTP control API.

New provider work should continue to compose the shared connector contracts and authority boundaries rather than creating provider-specific coordinator paths.

The reference product

The first reference application is a Git-native Verified Swarm Runner.

The target lifecycle is:

bounded repository task
        |
        v
   WorkUnit v0.2
        |
        v
 replaceable worker adapters
        |
        v
 candidate artifacts + ResultManifest
        |
        v
 verifier-owned EvaluatorPlan
        |
        v
 independent VerificationResult
        |
        v
 non-selecting evidence/reporting
        |
        v
 explicit human/governance integration decision

The key authority rule is:

worker success != acceptance
verification recommendation != merge authority
CI success != independent human review

The current codebase already implements substantial pieces of this trust path, but the end-to-end newcomer product is still being converged and experimentally validated. See EVOLUTION.md, ROADMAP.md, and the open project issues for the live gates.

Run the repository checks

For the repository's Python research/control code, the maintained POSIX convenience path is:

make setup
make test
make integration

If make is inconvenient, the portable direct-Python path is:

python -m pip install --disable-pip-version-check pytest
python -m pip install --disable-pip-version-check -r requirements-phase0.txt
python -m pytest -q

pytest.ini supplies the repository root on pythonpath, so pytest does not require a PYTHONPATH=. prefix. Windows/PowerShell commands are documented in CONTRIBUTING.md and docs/TESTING.md.

Validate the core Phase 0 contracts directly with:

python experiments/harness.py validate

Pull requests to protected main run the stable PR gate on Python 3.11 and 3.13 plus deterministic Markdown-link integrity. Individual subsystems also have narrower workflows.

Core architecture

IDKMesh is best understood as one layered system:

human constitution / governance
           |
           v
 goals + questions + evidence
           |
           v
       Work Units
           |
           v
 capability/resource matching
           |
           v
 isolated humans / agents / tools / compute
           |
           v
 candidate artifacts + provenance
           |
           v
 independent verification / criticism
           |
           v
 explicit integration decision
           |
           v
 canonical state + outcome evidence
           |
           +------> next goals / policy learning

The canonical lifecycle vocabulary—event, action, candidate, iteration, generation, learning, and improvement—is defined in ITERATION_MODEL.md.

For implementation-level boundaries, see ARCHITECTURE.md and the curated docs/architecture/ index.

What IDKMesh builds vs reuses

IDKMesh should spend its complexity budget on the parts that express its research thesis:

• goals, uncertainty, and evidence;
• bounded Work Units and authority;
• decomposition and dependency structure;
• capability/resource matching;
• independent verification and evidence aggregation;
• provenance and reproducibility;
• experiment/benchmark machinery;
• community and governance feedback loops;
• measured self-improvement under external authority constraints.

Commodity infrastructure should normally be integrated rather than reinvented. Current examples include Git/GitHub, OCI-style isolation patterns, A2A, MCP, and established provenance/supply-chain approaches.

Research discipline

The repository distinguishes at least four states:

1. implemented mechanism — code/schema/workflow exists;
2. synthetic validation — deterministic fixtures/simulations test mechanics;
3. observed evidence — controlled runs measured real behavior;
4. accepted conclusion — evidence is strong enough for the scoped decision.

Do not collapse these states. A simulator can validate an algorithm's implementation without proving that the algorithm improves real collaboration.

One flagship research family compares, under matched budgets:

one strong worker
vs one small worker
vs replicated workers
vs heterogeneous workers
vs specialized roles
vs task/evidence DAG teams

Important outcomes include correctness, hidden-test success, regressions, error correlation, reviewer time, compute/resource use, latency, integration conflict, provenance quality, and verified useful work per unit of scarce attention/cost.

The one question the research is organised around — when does adding another AI agent, as worker or verifier, increase independently verified useful work, and can that be predicted from a small pilot? — and its hypotheses, experiments, algorithms and audience are set out in the Scientific Program. RESEARCH_QUESTIONS.md is the longer idea backlog; see also docs/research/ and experiments/.

Project principles

Community first. Contributor experience, review capacity, and leadership scalability are engineering constraints.

Proposal is not proof. Human or AI confidence does not replace evidence.

Popularity is not correctness. Votes, stars, reputation, or correlated model agreement cannot override failed checks.

More agents are not automatically better. Diversity, independence, decomposition quality, and verification capacity matter more than raw count.

Uncertainty is data. Competing goals and unresolved hypotheses should remain explicit when evidence is insufficient.

Generation must not outrun verification. Output volume is harmful if the project cannot review, reproduce, and maintain it.

Integrate before reinventing. Reuse open standards for commodity capabilities and keep IDKMesh-specific semantics at the coordination/evidence layer.

Scale must be earned. Simulated or small-scale results must not be advertised as Internet-scale guarantees.

Cryptographic provenance comes before blockchain. Add heavier trust infrastructure only when a demonstrated threat model requires it.

Canonical authority remains external to generators and verifiers. Protected integration is a separate decision boundary.

Repository guide

New contributor

• CONTRIBUTING.md — contribution workflow and checks.
• COMMUNITY.md — participation paths and contributor ladder.
• SUPPORT.md — how to ask for help.
• CODE_OF_CONDUCT.md — community expectations.
• SECURITY.md — vulnerability reporting.
• CONTRIBUTORS.md — the contributors wall; every real contribution earns a place, not only merged code.

Understand the system

• docs/WHAT_IS_IDKMESH.md — framework, research, community, reference application, and self-hosting layers.
• ITERATION_MODEL.md — canonical evolution vocabulary and authority flow.
• ARCHITECTURE.md — current architecture map.
• EVOLUTION.md — strategy, implemented foundation, and next gates.
• ROADMAP.md — evidence-gated progression from the current state.
• docs/README.md — curated documentation navigation.
• docs/LOCAL_LOOP_TUTORIAL.md — hands-on walkthrough of idkmesh local-loop, local-loop-replay, and a decision recorded with local-loop-record-decision.

Contracts and interoperability

• schemas/README.md — current machine-readable contracts and versioning rules.
• docs/specifications/ — protocol/specification index.
• interop/ — protocol-neutral adapter boundary, A2A/MCP mappings, identity binding, and conformance helpers.
• IDKIPS.md — major improvement-proposal process.

Research and evidence

• docs/research/ — research programs and evidence.
• paper/ — canonical manuscript source and claim-to-evidence map.
• sim/ — deterministic simulations/analysis code.
• experiments/ — experiment definitions, harnesses, and results tooling.
• docs/audits/ — bounded audits and repository-health evidence.
• docs/findings/ — research and engineering findings.

Community, governance, and project memory

• GOVERNANCE.md and CONSTITUTION.md — authority and protected principles.
• COMMUNITY_GROWTH_ENGINE.md — ACE community-growth experiment and safeguards.
• PROJECT_RULES.md — repository-wide operating rules.
• docs/conversations/ — append-only structured collaboration history.

Public project record

The repository is the durable project record. Important conclusions from project work should be promoted into current architecture, specifications, decisions, findings, research evidence, governance, or implementation—not left only in chats or buried in historical notes.

Historical records remain valuable, but they should not silently override current canonical documents. See PROJECT_RULES.md and docs/README.md for the documentation hierarchy.

License

Apache License 2.0. See LICENSE.

Invitation

IDKMesh starts from a simple admission: we do not yet know the best way to coordinate intelligence at this scale.

If you can improve a question, falsify an assumption, reproduce an experiment, write a test, find a security problem, make a contract clearer, reduce reviewer burden, improve onboarding, or build one verified component, you can contribute.

From uncertainty to collective intelligence—through evidence.