How Grid Works Becomes a Canonical Capability Path

Release at a glance

Grid FYI now has a canonical answer to a basic question that previously required readers to assemble several films, Insights, use cases, capability filters, and developer links: how does Grid work from an accepted source fact to an accountable action?

The new How Grid Works capability spine is the concise public route. It organizes the architecture into six stages, names what each stage can contribute, states what a bounded test could verify, and keeps a visible limit beside every capability claim. It then connects the reader to a worked changed-fact trace, a claim-boundary matrix, four learning paths, nine contextual implementation handoffs, and four short technical films.

The companion How Grid Works: From Typed Facts to Accountable Action is the long-form route. At more than 3,000 words, it develops the same chain as a technical and operational argument. It defines the product vocabulary, specifies the contract at each transition, works through a reproducible fictional fixture, separates documented primitives from deployment claims, and supplies a failure-oriented evaluation protocol.

These two pages serve different depths without creating two competing explanations. The capability spine is the canonical map and routing surface. The Insight is the maintained deep guide. Both lead back to the same evidence boundaries and first-party developer material.

Six stages replace a pile of disconnected capability labels

The new path does not treat a capability list as an architecture. It places related capabilities inside six responsibilities that a reader can follow and test.

1. Connect governed sources

The authored operating contract should represent a value with identity, producer, revision, time, type, unit, quality state, correction relationship, and permitted purpose. This stage covers the interoperability boundary before calculation begins. A successful connector response can establish that a message was observed under a declared protocol; it cannot establish that the source is true, authoritative, current, permitted, or fit for the decision.

2. Build a shared, versioned model

Accepted facts bind to named formulas, relationships, rules, constraints, tests, owners, and effective revisions. Shared models and versioned logic address the private-copy problem without requiring one database, interface, institution, security domain, or decision authority. The model is shared at the level of represented meaning; access, execution location, and organizational responsibility may remain distributed.

3. Evaluate change and constraints

Reactive models, constraint evaluation, governed change, and live planning meet at this stage. When an accepted fact changes, declared dependents reevaluate while unrelated state remains stable. An authored decision model should keep unknown, stale, contradicted, infeasible, and authorization-required as different states rather than coercing them into a convenient number or green indicator. A feasible alternative remains a represented option, not an approved or executed act.

4. Project coordinated surfaces

Sheets, tables, maps, charts, documents, boards, applications, reports, and APIs can present role-specific views from one accepted model state. Coordinated views and multiple surfaces mean semantic alignment, not identical interfaces or universal disclosure. Each surface still needs an audience, permitted fields, transformation, accessibility and release requirements, freshness behavior, and revision identity.

5. Explain the result

Explanation should resolve to evaluated state rather than a plausible narrative. The evidence package can identify material inputs, source and model revisions, dependency path, constraints, alternatives, warnings, history, validation state, and unresolved conditions. A named reviewer can then test whether the represented result is reconstructable. That does not make the explanation complete, the sources true, the model substantively correct, or the conclusion independently validated.

6. Assist under human authority

AI and software may draft, translate, map, calculate, test, compare, and explain within declared permissions. Proposal, review, accepted model revision, authorization, execution, receipt, and verified outcome remain separate states. The record should identify the person or institution holding each consequential right and bind any approval to the exact revision reviewed.

The sequence is a contract, not a marketing funnel. A later interface or approval screen cannot repair an unidentified source, unreviewed rule, uncontrolled dependency, or missing authority upstream.

The chain stops before external action and begins again with evidence

The most important visual boundary on the new route sits after the six capability stages. Grid may prepare a payload, retain a represented authorization, call a configured interface, and store the response that comes back. The responsible external system and institution still determine whether an instruction was accepted, executed, received, lawful, appropriate, and effective.

That distinction matters across domains. A calculated payment is not an authorized transfer. A feasible transport plan is not a dispatch. An eligible case is not a determination or appropriation. A generated notice is not publication. A capacity result is not clinical assignment or facility acceptance. A command recommendation is not an order.

Receipts return evidence without erasing the boundary. Submitted, received, accepted, executed, and effective can describe different events, owners, clocks, and proof. A timeout may leave external effect unknown. A later acknowledgment may resolve one state without proving the underlying decision correct. The spine summarizes the invariant directly: calculated is not authorized; authorized is not executed; executed is not an outcome.

One worked change keeps the explanation concrete

The capability page uses the same deterministic Course Echo fixture available in the Change One Fact lab. A named logistics revision changes available transport from six to five. Six required movements at forty minutes per wave move from one wave to two. Completion moves from 08:40Z to 09:20Z against an 08:45Z window. Margin moves from five minutes to negative thirty-five, and the represented plan becomes infeasible.

That trace demonstrates why reactive behavior is more than refreshing a dashboard. The changed fact reaches the number of waves, completion time, window margin, feasibility state, role-specific views, and explanation. In this authored fixture, the earlier result can be reconstructed because the baseline and current states are retained; a deployment must also commit and retain the relevant source, model, and runtime identities. Demand, unaffected facts, and the authority state should remain stable.

The fixture does not reallocate a real transport, change a mission order, or create command authority. It is an authored oracle for testing change propagation, constraint integrity, view consistency, explanation, and stop behavior.

Developer handoffs now match the reader's question

Grid FYI owns business context, conceptual operation, authority boundaries, and evaluation framing. Grid Developers owns current product vocabulary, language, guided builds, integration contracts, operations, and runnable examples. The new spine connects those responsibilities contextually instead of sending nearly every reader to one generic destination.

The implementation path begins with Grid product concepts, then moves to the first reactive model. Readers examining provenance and review can use Explain and validate a decision. Readers evaluating role-specific interfaces can inspect workbook surfaces. A technical evaluator can then use example verification and the canonical Grid examples to compare declared sources, expected outputs, executable fixtures, and implementation references.

Those links make product primitives inspectable. They do not prove a customer's model, integration, security boundary, latency, resilience, operating authority, or intended-use suitability.

The path is now visible from the public site

The capability spine is surfaced as a first-class route rather than another item a reader must discover by filtering a large library. Homepage and navigation links now point directly to /how-grid-works. The homepage also presents the long-form guide as a technical starting point. The interactive lab and maintained editorial pages can return to the same canonical explanation.

The existing journeys remain important. From a Spreadsheet to a Shared Model helps a team recognize when a private file has acquired organizational responsibility. From a Changed Fact to Coordinated Action follows revision, dependency, alternatives, views, and authority through recognizable work. How to Evaluate Executable Decision Infrastructure converts the proposition into explicit gates, failure injections, evidence requirements, and a go, narrow, or stop decision.

The new route does not replace those materials. It supplies the missing order: understand the chain, inspect a worked change, choose the relevant evaluation path, and then continue into the exact developer documentation.

How to verify this release

1. Open How Grid Works and confirm that it presents exactly six numbered stages, a visible external action and receipt boundary, the Course Echo changed-fact trace, the layer-by-layer claim matrix, learning paths, contextual developer handoffs, and technical films.
2. Open the more than 3,000-word technical architecture guide. Confirm that its six-stage exhibit, contract table, Northstar fixture, responsibility boundaries, product-claim matrix, evaluation protocol, and developer links remain available as ordinary readable content.
3. Use the Imagine lab to change available transport from six to five. Confirm the authored transition from one wave to two, 08:40Z to 09:20Z, positive five to negative thirty-five minutes, and feasible to infeasible, without presenting the model as command authority.
4. Open the evidence model and confirm that conceptual, illustrative, research-grounded, product-demonstration, customer-controlled, and independently validated claims remain distinct.
5. Open How to Evaluate Executable Decision Infrastructure, From a Spreadsheet to a Shared Model, and From a Changed Fact to Coordinated Action. Confirm that the conceptual, migration, changed-fact, and evaluation routes form a coherent path rather than repeating one undifferentiated claim.
6. Follow the first-party developer links for product concepts, the first reactive model, explain and validate, workbook surfaces, example verification, and canonical examples. Confirm the displayed label and destination match the capability question that precedes each handoff.
7. Build the static site and confirm that /how-grid-works, /insights/how-grid-works, and this permanent release route appear in generated navigation, metadata, sitemap, and link validation without replacing the existing use-case, Insight, evidence, or Imagine routes.

Evidence, availability, and remaining proof

Public means the named Grid FYI routes and navigation are included in the public site build associated with this release record. It is an editorial availability statement. It does not mean that every architecture element is enabled in every Grid environment, that a connector exists for a particular system, or that a customer has configured and accepted the depicted operating chain.

The product-demonstration evidence level applies to the publication experience: the canonical spine, long-form guide, worked editorial fixtures, internal routes, and contextual links can be inspected. First-party Grid Developers documentation supports statements about documented concepts and implementation paths. It is not independent evidence and does not establish production behavior beyond its declared examples and scope.

A larger claim requires a larger test. Customer-controlled evidence requires the customer to control material sources, model rules, environment, cases, operators, authority mapping, failure injections, and acceptance thresholds. Independent validation requires an appropriate evaluator, disclosed method, declared scope, and reproducible evidence. Security authorization, legal or policy compliance, accessibility conformance, regulated validation, operational suitability, external authority, and real-world outcomes remain separate claims owned by the responsible institutions.

This release therefore establishes a clearer public learning and evaluation path. It does not turn that path into proof of the system or decision it describes.