How Grid Works: From Typed Facts to Accountable Action

The important question is not whether a number can be calculated

Most consequential work already contains calculations. Hospitals estimate staffed capacity, logistics organizations combine inventory with routes and time, public programs test eligibility and funding limits, and command staffs compare courses of action. The difficult part is maintaining the chain that lets a reviewer determine which facts, rules, constraints, assumptions, views, and authorities produced a result after the world changes.

Traditional systems split that chain across sources, extracts, spreadsheets, scripts, dashboards, briefings, and workflow tools. Each component may work locally while the decision breaks at the seams: a correction reaches the dashboard but not the briefing, a copied formula changes a default, or an AI explanation describes a plausible rationale rather than the calculation that ran.

Grid's proposition is one governed computational object whose facts, derivations, constraints, projections, and review state have explicit identities and testable connections. Sources and institutions can retain ownership.

The product vocabulary matters. Grid Developers describes a workbook as the user-facing container and a model as the executable state behind it. A binding associates an address with a value or calculation, and dependencies are reactive: when an upstream value changes, affected derivations update. A formula expresses a relationship; a rule reacts to state or time; a connector introduces external data; and a workbook surface projects model state into an interface. The complete vocabulary is available in Grid product concepts.

Those primitives are not the entire operating design. Implementers must still name source and rule owners, promotion and uncertainty policies, audiences, decision authorities, and external acknowledgment. Computation alone cannot supply institutional legitimacy.

The six stages form a contract, not a marketing funnel

Each stage consumes a bounded object and produces another. Deployments need not be linear: sources may be federated, models may compose, and review may send a proposal back. Each transition must remain inspectable.

Stage	Accepted input	Required invariant	Produced object	Stop condition
Governed sources	Observation, record, event, or authorized manual entry	The authored operating contract declares identity, type, units, effective time, source owner, quality state, purpose, and correction relationship	Accepted source revision	Missing, stale, contradictory, unauthorized, or unmapped input
Shared and versioned model	Accepted facts plus governed assumptions	Named relationships, model version, tests, ownership, and promotion state are explicit	Versioned model revision	Invalid units, unresolved mapping, failed test, or unapproved logic
Reactive constraint evaluation	Source and model revisions	Only declared dependencies move; the authored model explicitly represents and tests unknown and infeasible separately from false and zero	Evaluation state and alternatives	Unresolved fact, violated hard constraint, expired assumption, or required authority
Coordinated surfaces	One accepted evaluation state	Every projection identifies its audience, fields, transformations, and bound revisions	Role-specific sheet, table, map, chart, document, board, or app	Disclosure, semantic-parity, accessibility, or freshness failure
Explanation and evidence	Result plus execution context	When referenced source, model, and runtime identities plus the relevant history are committed and retained, inputs, dependency path, validation, warnings, and versions can be reconstructed	Reviewable evidence package	Unexplained material difference or incomplete record
AI assistance under human authority	Scoped context and permitted operations	Proposal, review, authorization, execution, and receipt are separate states	Reviewed proposal or authorized instruction	AI exceeds scope, evidence is insufficient, authority is absent, or external system rejects action

A stage is complete only when its produced object and stop conditions can be tested, not when a screen looks complete.

1. Governed sources preserve meaning before calculation begins

A source value is more than a payload. 12 might mean beds, staffed beds, cohort-eligible beds, or hours. A timestamp might describe observation, transmission, acceptance, or effect. A blank can mean unreported, inapplicable, withheld, unavailable, or zero. If those distinctions disappear at ingestion, later precision is cosmetic.

A decision-relevant revision should retain producer, record identity, schema, type, units, observation and effective time, quality state, permitted purpose, release marking, and correction relationship. The source owner remains responsible for meaning and acceptance. Successful connector transport does not prove truth, timeliness, permission, or fitness.

Typed facts give the model an enforceable vocabulary. Currency should not add to a count, a duration should not compare with an unzoned timestamp, and a percentage should not drift between 0.21 and 21. Validation should reject or isolate writes that violate the contract.

Public-sector and defense governance also includes purpose and jurisdiction. One partner's fact may not be releasable to another, and a local result may be only an input to another institution's decision. Interoperability means a declared exchange contract, not indiscriminate pooling. The coalition coordination use case preserves source, computation, release, and action authority across sovereign boundaries.

2. A shared, versioned model turns facts into maintained relationships

A shared model is a governed set of bindings, formulas, predicates, rules, constraints, assumptions, and tests with durable identity. Spatial addresses can coexist with semantic names: B7 may also be UsableCapacity. The name makes the relationship legible while the address preserves familiar workbook interaction.

Versioning applies beyond data. Rules can be approved before they are effective; thresholds can vary by jurisdiction; assumptions can expire. A model revision should declare its change, owner, tests, review and promotion state, and effective scope. Replacing a formula without retaining prior identity breaks reconstruction.

The model can represent contradictions instead of erasing them: sources may disagree on capacity, an open route may have an unknown vehicle class, or an eligible case may lack funds. A reconciliation rule may choose a value only when the organization authorizes that rule.

This prevents maps, dashboards, documents, APIs, and AI explanations from carrying private rule copies. They bind to a model-owned result or declared projection. From a Spreadsheet to a Shared Model provides a migration path; From Common Operating Picture to Common Operating Model develops the organizational architecture.

3. Reactive evaluation follows the affected path and preserves refusal

Authors declare relationships and Grid maintains dependency order. When a source binding changes, affected derivations reevaluate without requiring a person to find every copy. The first reactive model tutorial demonstrates this with typed cells, formulas, an override, classification, and summary.

Reactivity needs constraint semantics. The model must distinguish failure, unavailable input, staleness, contradiction, authorized override, and calculation error. It must not turn missingness into zero or infeasibility into a convenient plan.

Constraints may be quantitative, temporal, logical, spatial, procedural, or jurisdictional: capacity covers demand, actions fit a window, routes support loads, assignments do not conflict, and reviewers hold required delegations. Some can be solved; others require an authorized person to change a requirement or accept risk.

The right output can be a precise refusal: infeasible under revisions S-18 and M-4, source too stale, or feasible alternative; authorization required. Grid should explain those states, not disguise them as green.

A small changed-fact model

Consider Exercise Northstar, a fictional, non-operational incident-support exercise. Three packages require 48 kit-equivalents: Alpha 20, Bravo 18, and Charlie 10. Partial packages and substitution are disallowed. No real organization, patient, unit, route, or emergency is represented.

East reports 40 kits, eight reserved, and lane throughput of 36. West reports 30, six reserved, and baseline throughput of 28. With usable = MIN(on_hand - protected_reserve, lane_throughput), East is MIN(32, 36) = 32, West is MIN(24, 28) = 24, total usable is 56, and margin over demand is eight.

The authored baseline assigns Alpha and Charlie to East, using 30 of 32, and Bravo to West, using 18 of 24. This is capacity-feasible. It is not a dispatch order.

At exercise time 09:20, accepted source revision W-LANE-08 corrects West lane throughput from 28 to 12. Nothing else changes. The dependency path is West lane revision -> West usable capacity -> total usable capacity -> capacity margin -> authored plan feasibility -> role-specific views and explanation.

Binding or state	Baseline revision	Corrected revision	Rule or test	Observable consequence
east.usable	32 kits	32 kits	MIN(40 - 8, 36)	Unaffected; East source and dependencies remain stable
west.usable	24 kits	12 kits	MIN(30 - 6, lane_throughput)	Changes because lane throughput is the limiting term
total.usable	56 kits	44 kits	east.usable + west.usable	Falls by 12
required.total	48 kits	48 kits	20 + 18 + 10	Unaffected; requirements were not revised
capacity.margin	+8 kits	-4 kits	total.usable - required.total	Crosses the hard feasibility boundary
Authored allocation	East 30; West 18	East 30; West 18	Each site assignment must not exceed usable capacity	West exceeds its revised capacity by six
Evaluation state	Capacity-feasible	Infeasible	Margin and site constraints must both hold	Prior plan is preserved but invalidated for the current revision
Authority state	Not authorized	Not authorized	Named exercise authority must accept an exact plan revision	No change; calculation never implied authorization

The correction does not permit releasing reserve, splitting a package, changing demand, extending the window, or inventing a site. An optimizer or AI may propose alternatives, but each changes a separately owned constraint. Reserve, requirement, site, and window owners must supply the corresponding authority or source revision.

The negative oracle matters. West and total capacity, margin, allocation feasibility, dependent surfaces, explanation, and pending proposals should change. East capacity, demand, reserve, model revision, and authority state should not. More change indicates uncontrolled blast radius; less indicates stale state.

4. Coordinated surfaces present one state for different work

People need role-fit interfaces. Operators may need assignments, planners a map and alternatives, reviewers assumptions and exceptions, executives material constraints, and auditors the revision chain. Different interfaces need not produce different answers.

Grid Developers describes sheets, tables, maps, charts, documents, boards, datasets, apps, and custom views over model state. Configuration and interactive state are model-addressable while the reactive model remains behind the interface. The workbook surfaces documentation distinguishes workbench and app-oriented presentation.

Coordination requires semantic parity, not visual identity. A Northstar map can emphasize West, a table show the six-kit site overage, and a brief state the four-kit deficit. Each binds to the same revisions. A partner view may omit reserve detail while retaining status and revision identity.

Each surface should declare audience, permitted fields, transformation, refresh behavior, accessibility, and revisions. Test that change appears everywhere it should, nowhere it should not, without a private formula fork. One Program Rule, Many Public Surfaces examines conformance across staff tools, public explanations, reports, and APIs.

5. Explanation and evidence make the calculation reviewable

An explanation is a route through evaluated state, not a fluent paraphrase. For Northstar it identifies W-LANE-08, derives West capacity of 12, names affected bindings and violated constraints, states what remained stable, and binds to exact revisions.

Grid Developers' explain-and-validate tutorial demonstrates dependency inspection, saved history, comparison with prior revisions, quantified uncertainty, guarded inputs, validation, and presentation rules. Those primitives help answer different questions:

• Why did this result move? Follow the evaluated dependency path.
• What changed from the accepted baseline? Compare saved revisions rather than relying on memory or screenshots.
• What writes are permitted? Exercise type and validation contracts, including expected rejection.
• How uncertain is the result? Keep uncertainty distinct from the point estimate and decision rule.
• Did presentation change the calculation? Verify that formatting and surface behavior do not masquerade as model changes.

Evidence includes source identities, model version, environment, inputs and outputs, warnings, trace, tests, review, and external receipts. A receipt proves only what it says: submitted, received, accepted, and effective are distinct, and none proves the decision correct.

A trace can show how represented inputs produced an output. It cannot prove a source true, an interpretation lawful, a model complete, or an action wise. Those require appropriate evidence and qualified judgment.

6. AI can assist the model without owning the decision

AI can propose source mappings, formulas, constraints, surfaces, trace summaries, tests, or changed-fact alternatives. Each contribution should land as a named, reviewable object rather than silently becoming production state.

The control record identifies supplied revisions, permitted operation, context, change set, tests, warnings, reviewer, disposition, and any promoted revision. Check AI explanations against traces and formulas against tests. Alternatives retain changed constraints and required authority.

"Human in the loop" is too vague. Name who holds each right, for which jurisdiction, amount, event, channel, and time; whether AI may read, simulate, draft, stage, submit, publish, or execute; which actions are denied; and whether approval binds to the reviewed revision.

In Northstar, AI may note that four kits restore total capacity. It may not release reserve, revise requirements, dispatch, or report completion. A qualified authority may accept an exact plan; another system may execute it and return a receipt. External execution remains outside Grid authority.

The Authority Contract for AI-Assisted Decisions provides the control model; AI with Human Authority offers a shorter path. Proposal, review, authorization, execution, and verified effect remain distinct.

Product primitives are not deployment claims

Put these boundaries in the evaluation plan and any resulting decision brief.

Documented or testable proposition	What it supports	What it does not establish
Grid documentation describes typed values, bindings, formulas, rules, connectors, and reactive dependencies	A product-level hypothesis that decision relationships can be represented and reevaluated	Correctness or completeness of a customer's model, source mappings, or domain interpretation
Grid documentation describes workbook surfaces over model state	A product-level hypothesis that several interfaces can bind to one represented state	Accessibility, semantic parity, usability, disclosure safety, or adoption in a particular environment
History, dependency inspection, validation, and examples can be exercised	A basis for a bounded hands-on test with expected outputs and failures	Independent audit, certification, accreditation, security authorization, or regulatory compliance
A connector or external function can be configured	A technical path for controlled exchange	Availability of a required connector, data rights, cross-domain approval, delivery guarantee, or acceptance by the external system
AI can draft or propose model artifacts	A reviewable authoring-assistance pattern	Authority to approve logic, decide, publish, spend, dispatch, treat, command, or create legal effect
A synthetic fixture passes its acceptance tests	Evidence about that fixture, build, environment, and test boundary	Production scale, latency, resilience, mission suitability, outcome improvement, or transfer to another domain

Official docs are product documentation, not independent evidence. They do not prove service levels, security, records, privacy, accessibility, accreditation, or operational suitability. Those claims require customer-controlled testing and, where appropriate, independent validation.

Evaluate the chain by changing one fact on purpose

A useful evaluation is understandable and strict enough to fail. Select one bounded decision, build a synthetic or de-identified fixture, and record its expected path and oracle. Use the decision evaluation worksheet and evaluation guide for the broader evidence plan.

Evaluation dimension	Seeded test	Acceptance evidence	Important failure
Source governance	Send valid, stale, corrected, duplicate, contradictory, wrong-unit, and unauthorized values	Accepted/rejected state, source identity, timestamps, correction chain, and reason	Bad input is coerced, accepted silently, or loses provenance
Dependency precision	Change one source with a predeclared affected and unaffected set	Current values, prior revision, dependency trace, and exact changed bindings	Stale dependent result or unrelated recalculation changes state
Constraint integrity	Cross a hard threshold and remove a required fact	Distinct infeasible, unresolved, stale, and authorization-required outcomes	System invents a feasible answer or treats unknown as zero
Surface conformance	Compare sheet, table, map, document, app, export, and permitted partner view	Revision identifiers, field-level parity checks, allowed transformations, and disclosure test	A surface implements private logic or exposes restricted data
Explanation	Ask why before and after the changed fact	Trace to accepted inputs, formulas, constraints, history, uncertainty, and warnings	Narrative is plausible but unsupported by evaluated state
AI and authority	Request an allowed proposal and several denied actions	Prompt/context record, change set, tests, reviewer disposition, denied-call logs, and exact authorization binding	AI promotes logic or triggers external effect without the declared authority
External boundary	Submit through a test adapter; return rejection, timeout, duplicate, and later acknowledgment	Idempotency key, outbound instruction identity, external receipt, retry state, and reconciliation	Grid equates send with receipt, receipt with acceptance, or acceptance with effect

Run the baseline twice, commit it before demonstrating history, then change only the seeded fact. Confirm affected and unaffected sets. Test denied writes and missing evidence. Repeat through required surfaces and export enough evidence for another evaluator to reconstruct the conclusion.

Measure performance after correctness is stable. Report volume, model size, dependency shape, concurrency, hardware, network, warm/cold state, percentiles, failures, and recovery. Do not translate a small fast demonstration into a production claim.

Grid Developers' canonical examples make expected behavior inspectable, but do not replace customer sources, controls, authority, failure modes, or thresholds.

A practical route through the material

Start with From a Changed Fact to Coordinated Action, then change capacity in the Imagine lab. Technical teams can build the first reactive model and use explain and validate to inspect history, dependencies, and write contracts.

For public missions, compare health-system capacity with coalition coordination. Both share calculation while preserving institutional authority. Use the evidence model to label conceptual, documented, demonstrated, customer-controlled, and independently validated claims.

Connect facts without stripping meaning; encode relationships without hiding versions; react without inventing certainty; project many surfaces without many truths; explain without overstating proof; and use AI without transferring authority. Stop at the external boundary, retain the configured request-and-response evidence, and let the authorized institution own the act.