Launching and Engaging with Epistemedia

Source content

Launching and Engaging with Epistemedia

For a reader

Start with the four-case failure-mode map on the homepage or How We Know index: overgeneralization, false independence, a missing comparison class, and scope inflation. Each case page is a reproducible projection, not an anonymously edited canonical article. Inspect its frontier, policy, source objects, and manifest. The versioned public mission and current-state limits are compiled separately at /about/.

The self-describing Substrate topic pages remain a repository projection. Their experimental lens routes preserve the same included-object inventory, so do not interpret different labels or manifest IDs there as materially different editorial views. encyclopedia is the public default until another lens has observable selection or semantic differences.

For an agent consuming knowledge

1. Retrieve /llms.txt or the nearest path-scoped llms.txt.

2. Select Markdown, JSON, API, MCP, CLI, or bundle access based on the task.

3. Preserve catalog, frontier, policy, compiler, object, and source identities.

4. Do not report a projection label as universal truth.

5. Distinguish the bootstrap topic projections from accepted dossier policy views: repository artifacts do not encode challenge, qualification, or source-independence relations, while a reviewed dossier can expose those relations explicitly.

6. Cache immutable objects by digest; revalidate mutable aliases through status or release manifests.

For a person contributing through an agent

1. Point the agent to the repository or an open task URL.

2. Have it run make orient and python -m epistemedia repo next.

3. Select one bounded immutable task contract.

4. The agent creates a branch, implementation, tests, generated artifacts, and run receipt.

5. Untrusted CI validates without secrets.

6. An independently rooted trusted integrator applies accepted promotion predicates.

7. The accepted merge becomes a new repository and public-catalog frontier.

For a realm operator

A realm can remain private and local-first. It chooses its own constitution, ontologies, epistemic policies, disclosure, accepted imports, and exports. Sharing a bundle does not grant the receiver authority over its local state. Public Epistemedia is one realm and reference implementation, not the universal center of the network.

For an integration builder

Use the static OpenAPI document with the local gateway, local stdio MCP for agent clients, the CLI for local workflows, and downloadable public projections for offline operation. The hosted API and MCP destinations remain reserved until provider read-back proves them. Avoid scraping HTML when structured objects are available. Implement content-digest verification and surface manifest metadata to downstream users.

Current public corpus

Epistemedia still dogfoods itself through Explore, where the self-describing corpus compiles the project’s constitution, architecture, policies, task contracts, implementation, tests, security model, governance, and release records. Case 001 remains the homepage lead; the How We Know index lists four independently reviewed evidence files, each compiled into exact-source and two policy-relative projections. This is a bounded application-level library, not the normative replay graph or broad knowledge coverage. Hosted API and MCP remain unverified until external read-back proves them.

The public mission is an owner-approved, versioned project statement. It is not evidence, policy, constitution, or a stored verdict. Its current-state flags must continue to distinguish implemented local interfaces from externally verified hosted services.