How Grid works
A model is the facts, rules, and calculations behind a decision. Grid gives that model one shared home, updates the right results when a fact changes, and keeps every approved view aligned.
It can calculate and explain. The people and systems with real authority still decide and act.
Manufacturing explainer · 1:30
A changed manufacturing fact breaks a six-company plan; Grids shows what still works while commitments, quality, and execution remain in human hands.
▶ 1:30
Interactive planning scenario
Six required movements take forty minutes per wave. When available transport falls from six to five, the work needs two waves and misses an 08:45 window.
The changed fact updates the wave count, completion time, remaining margin, and feasibility state. A predefined alternative can be checked next.
Nothing here reallocates a real vehicle, changes an order, or grants authority. Those actions still require the responsible person and evidence from the external system.
One model · Six jobs
Each step has a specific job. If a source, rule, or authority is unclear at one step, a polished interface later in the chain cannot fix it.
Keep the producer, time, revision, unit, and permitted use attached to every important input.
Represent the facts, formulas, dependencies, constraints, tests, owners, and revisions in one reviewable place.
Update the results that depend on a changed fact, keep unrelated state stable, and show when a plan no longer works.
Present sheets, maps, documents, applications, reports, or APIs from the same current model without copying the calculation.
Expose the important inputs, rules, dependency path, constraints, warnings, and retained history needed to review the result.
Let software and AI draft, calculate, compare, and explain without turning a proposal into an approval or real-world action.
A successful source connection, calculation, interface, or approval screen should not inherit a larger claim than its evidence supports. See the full evidence model.
| Layer | Inspect | A small test can show | It cannot show by itself |
|---|---|---|---|
| Source | Identity, revision, time, unit, validation, correction | The exact value accepted by the fixture | Truth, authority, completeness, or fitness for use |
| Model | Names, formulas, dependencies, constraints, tests, version | Execution fidelity for declared cases | That policy, doctrine, science, or judgment is substantively correct |
| Evaluation | Affected path, alternatives, uncertainty, infeasibility | Expected change propagation under stated conditions | Selection, permission, operational suitability, or effect |
| Surface | Audience, fields, transformation, revision, release rule | Semantic parity across the tested views | Universal access, accessibility conformance, or workflow adoption |
| Explanation | Inputs, intermediate values, rules, history, evidence links | Reconstruction by the named reviewer | Independent validation, legal sufficiency, or complete causality |
| Authority | Role, scope, delegation, reviewed revision, recorded act | That the fixture enforced its represented boundary | Real-world authority, authorization to operate, or an achieved outcome |
Continue
Choose the shortest path that answers the question you have now.
Go deeper on sources, rules, changed facts, views, explanations, and authority.
Watch one planning input move through timing, feasibility, views, and the human decision boundary.
Define the inputs, failure cases, success criteria, evidence, and stop conditions before trusting a demonstration.
These guides cover the product concepts, source connections, first model, explanation tools, views, external functions, examples, and production planning.
Workbook, model, binding, cell, symbol, formula, predicate, rule, connector, and surface.
Inspect connector ingress, event admission, bindings, idempotency, backpressure, and the boundary between receipt and source truth.
Create typed inputs and named derivations, then prove the dependency graph by changing one value.
Trace dependencies, compare saved state, keep uncertainty distinct, and test authored write contracts.
Study how sheets and purpose-built surfaces present model-backed state without becoming separate calculation systems.
Separate host-admitted network or secret capability from the institutional authorization behind a consequential act.
Use declared source, expected output, and verification contracts to make a narrow behavior claim repeatable.
Use small runnable examples and their expected outputs as implementation references—not as proof of deployment suitability.
Review production concerns and preserve the difference between a documented runtime path and an authorized deployment.