Microcosm

• It is meant as a way in. You can start from the map, open a component, and read its evidence record, source reference, and the line on what it does not prove, so nothing here asks you to take a summary on trust. The public repository carries the standalone source slice and its local checks.
• If something here is confusing, or claims more than it shows, I would rather hear it. Please let me know.

1. 1Clone the repository.
2. 2Run the quickstart check and inspect the result record.
3. 3Read the evidence kind, rank, real-tool marker, and the line that says what the pass does not prove.
4. 4Inspect one component card, such as the cold-reader route map, and follow its source link.
5. 5Read where the public record stops, and check the site never claims past it.

• Each of the seven areas carries component records for the public slice. Formal math and proof has a Lean and Lake proof-witness pipeline, premise retrieval, tactic routing, and verifier-trace repair. Agent reliability and safety replays sabotage, sandbox-escape, prompt-injection, and memory-poisoning cases. Research and science covers finance forecasting, a spatial world model, and a replication rubric. The rest cover source import and drift control, architecture and navigation, work and continuity, and entry and orientation.
• The populated source slice is designed to run locally against a folder and write readable state without external model calls. The public repository contains the standalone source slice; non-public internals stay out or appear only as explicit public-safe stubs.
• Most bind to one shared path that runs from a project on disk through to a result you can read.
• Each component declares its own evidence: a class, a strength rank from 1 to 5 for how independently it is checked, and a line on what it does not prove. The card gives you that, so you can judge it on the evidence rather than the wording.
• Some components run real tools: the Lean prover, Lake, finance statistics, git provenance checks. Others derive their verdict over copied source or a declared contract against small synthetic fixtures. Each card says which, in plain language.

Reads as

78 components

Means

78 public component contracts, each with its own evidence line

Does not mean

product maturity, or whole-system correctness

To check it

open a component card, read its evidence class and rank, then the line on what it does not prove

• Running a real tool and earning a high rank are separate signals. A real-tool run is bounded to a small scope on purpose, so it is capped at 4: a bounded run proves less than a check that derives its own verdict. The evidence page ranks all 78 and says what each class checks.
• A fixture-bound replay is not a product substitute. It is the public-safe form of a mechanism that should not be disclosed as live private-system authority: it exposes the mechanism, the boundary, and the refusal, not a running service.
• The weakest class is honest about being weak: it confirms a fixture is well-formed. That is shape, not behaviour, and the components that carry it say so on their own card.

• One case is a real agent trace whose "committed, clean" completion note lacked a final delta and any terminal validation; the claim is lowered, not accepted.
• One plants fabricated commit, ledger, and test-pass claims in a fixture completion note: real git and pytest witnesses block each one with a typed error code.
• One takes a monitor's "coverage complete, cleared" sign-off and reduces it to what its probes actually backed. A verdict is not authority; its evidence is.

• It is standalone code you can run, with non-secret source copied and checked against where it came from, and result records over small synthetic fixtures.
• The fixtures are there for a reason: they are how a piece of the work can be shown without shipping the live system it normally runs against. Where a component only checks the shape of a fixture, its card says so.
• You can inspect the public map with no special access: run the quickstart, read the ranks, open the source paths, and follow the records.

Work in motion

See how the system watches its agents run

An agent-trace workbench: a live fleet of runs streaming in. Opens the agent-observability runtime in the public map.

Open in the map →

Domain execution

See a research workload running

A market-intelligence view: records on the left, an inspector on the right. Opens the finance-forecast evaluation spine in the public map.

Open in the map →

‹ ›

Open a view to land on its node in the public map. There you can select any node to inspect it, then open it (double-click, or press Enter) to follow it into the component, its evidence record, and the source on GitHub. The blur is baked into the image, not a filter that can be switched off. Additional code-map, orientation, inspection, and component views are prepared privately and added only when their source-capability receipts exist.

1. 1Start from a component card and its evidence record here.
2. 2Run the quickstart check before expecting broad component behaviour.
3. 3Read how each component is checked: the 1-to-5 rank and the line on what it does not prove.
4. 4Compare a strong component with a weak one. The weak ones say so on their own card; check that they are right to.
5. 5Read where the public version stops, and confirm the site never claims past it.

Read this repository as a calibration reviewer. First, by area, name the strongest components and what each actually does, with its evidence class. Then judge both directions: where the wording claims more than the evidence shows, and where it undersells what a component demonstrates. Do not reduce the system to a set of projections; computed projection is one evidence class among several.

1. 1Run the review route and tell me where a claim reaches past its evidence, or where the wording undersells what is there.
2. 2Open an issue or start a discussion if a component claims more than it proves.
3. 3Tell me what I have got wrong, or what you would do differently. I'm a student without industry experience, so a careful outside read of the design, the boundaries, or the writing helps more than anything.

The model time this runs on comes out of a student budget I cover myself, so it is the real limit on how fast the work moves. Feedback is still the most useful thing you can give; if you would rather help with the compute side, the email above is the way to do it.

Public security contact: repository security policy · GitHub source

Every area names the public source path it maps and the evidence record that bounds it. The website, reader digest, and repository should agree on the public source slice and its scope limits. If you are pointing an automated agent at Microcosm today, give it the repository, public packets, and this site.