How the program, tools, and engine fit together.

1. A calculator’s Why view

A calculator has a function that computes its results and a configuration that names its controls and outputs. A graph configuration can also declare curves, intersections, and areas. In the market example, the function builds demand, supply, and taxed-supply lines; the graph declares the intersections and surplus regions.

At compile time, analysis identifies dependencies and source locations in those calculations. The generated runtime captures intermediate values as the program runs. Why combines the analyzed structure with the values for the current inputs, so you can expand a result into the steps that produced it.

The author does not supply a separate explanation tree. Analysis provides structure that the final number alone cannot tell you. Available detail depends on the expression and source metadata; unsupported edges are marked as boundaries.

2. Lenses and diagrams

A lens selects the facts relevant to a particular question. The organization lenses show definitions, dependencies, recurring type shapes, and repeated bodies. The access lens checks how a service uses its database keys.

Start with the named building blocks: browse definitions grouped by package and checked type, then see which definitions use a block and what it uses. Other lenses compare recurring patterns or show effect relationships. Counts and sizes are available as supporting detail in the browser.

The structural facts come from static analysis of the type-checked program. Editing the source and rerunning the same analysis produces a view of the changed program. Recorded website figures are regenerated from their sources during the build and checked for drift.

Authors can also declare related definitions and reading orders, and supply JSON views that choose emphasis in a text lens. Those references and supported structural claims are checked against the program. Free-form captions remain authored commentary; their meaning is not proved by those checks. Read what is generated, checked, and authored →

A dependency map describes structure; it does not prove that the design is good. The access checker covers particular access rules, not every possible defect.

3. Service checks and execution

A Bosatsu service declares routes, handler functions, and policies. The server engine handles HTTP and interprets the handlers’ effects, including database operations. This separates the implementation of the server from the application logic that Yichus analyzes.

Generated API applications include their input-file definitions and the library functions and values those definitions depend on. Unused library guides and examples stay out of the application bundle. The developer MCP still supplies its guide and tool catalog, and a program that explicitly uses that catalog keeps it. The host runtime supplies external operations.

In the Notes example, the access analysis identifies a handler reading a fixed user’s row. Running the handler as a different user demonstrates the wrong result. Changing the key repairs that defect; rechecking and rerunning test the change in those two ways.

The host engine can use libraries from its implementation language, so each application does not need a Bosatsu database driver or HTTP stack. New integrations still need adapters, and the exposed operations determine what the tools can analyze. Read why this helps a small language support useful applications →

Other checks explore request interleavings or delivery and crash schedules in a declared model. Each result has assumptions and bounds. A recorded execution shows what happened on its inputs; it is not a proof about all inputs. Compare access, schedule, protocol, law, and conformance checks.

Language and runtime responsibilities

Bosatsu supplies the language, type checker, and compiler. Its language-defined functions are checked for recursion and pattern coverage. External operations and host runtimes remain trusted and tested parts of the system; these language checks do not make a server or event loop terminate.

Yichus’s explorer analyzes Bosatsu’s typed intermediate representation, called Matchless, along with compiler metadata. These tools inspect the application logic expressed in Bosatsu. Host engines and integrations can remain in other languages; checks over their operations rely on the stated contracts and do not inspect the host implementation itself.

4. Frontend updates from compiled bindings

The UI compiler can identify which state values feed particular DOM properties. For supported expressions, it emits bindings that tell the runtime which element and property to update. The counter formats a new number and patches its text without rebuilding the application. Structural changes can take other render routes.

The frontend benchmark compares compiled Yichus with real React implementations. It measures how quickly each runtime accepts update calls, not which one finishes rendering sooner. It does not establish a general rendering-speed advantage.