One Program Rule, Many Public Surfaces

The public should not have to find the right copy

A public program can have one policy and many answers.

The staff case tool implements one eligibility threshold. The public website paraphrases another. A notice template still uses last year's exception language. A monthly report calculates its denominator from an older definition. A partner API returns a decision code but not the rule revision that produced it. The differences may begin as ordinary maintenance. They become consequential when two people or systems receive conflicting accounts of the same program.

This is not mainly a content-management problem. Each surface may contain executable meaning: a calculation, a predicate, an effective date, a reason code, a field definition, or a branch for an exception. Copy the meaning and every copy becomes an implementation that must be governed, changed, tested, and reconstructed.

The answer is not one universal screen. Staff, applicants, call-center personnel, auditors, program leaders, and partner systems have different purposes and permissions. The stronger proposition is one governed rule package with several explicit surface contracts: each surface receives the same accepted semantic revision, presents only what its role and channel require, and preserves its own accessibility, privacy, records, and review obligations.

This paper distinguishes the public institutional direction from that Grid proposition. Federal sources establish responsibilities for authoritative digital services, information management, interoperability, accessibility, and records. They do not prescribe Grid or establish that this architecture satisfies a program's law, policy, or operating requirements.

What the federal direction establishes

The 21st Century Integrated Digital Experience Act sets standards for new or redesigned public websites and digital services, requires review and modernization prioritization for existing ones, and directs agencies to make public-facing applications and services available digitally to the greatest extent practicable. It also requires public-serving paper forms to be made available digitally while preserving an accessible non-digital path for people who cannot use digital services. Its standards address accessibility, consistent experience, user needs, security, and mobile use. The statute creates a service-delivery direction; it does not determine the substantive rule for any program.

OMB Memorandum M-23-22, Delivering a Digital-First Public Experience makes the consistency problem explicit. OMB says agencies are responsible for the quality, objectivity, utility, and integrity of the content they disseminate. It warns that outdated or duplicative content can confuse the public about which answer is authoritative, calls for consistent answers to common questions, and directs agencies to establish content strategies, review controls, and accountable ownership. “One Answer” in that memorandum is a content-governance principle, not a mandate for one software runtime.

OMB Circular A-130, Managing Information as a Strategic Resource, reaches beyond websites. It calls for information systems and processes to support interoperability and access where appropriate through documented, scalable APIs and open machine-readable formats. It also requires accessibility, records-management functions across the information lifecycle, privacy and security risk management, designated roles, and information that is timely and fit for lawful public access and reuse. An API is therefore one governed information surface among others, not an exception to program policy.

Accessibility applies across surfaces. The U.S. Access Board's Revised Section 508 Standards cover federal information and communication technology, including public-facing content and specified non-public-facing electronic content that constitutes official agency business. Covered categories include an initial or final administrative decision adjudicating a claim or proceeding, a notice of benefits or program eligibility, forms, acknowledgments, and policy announcements. A shared semantic model does not make any rendered page, document, or application accessible; each delivered surface still requires applicable design, content, and conformance evaluation.

Records also attach to the lifecycle, not merely to a final PDF. The National Archives and Records Administration's Universal Electronic Records Management Requirements organize baseline needs around capture, maintenance and use, disposal, transfer, metadata, and reporting. NARA presents them as a starting point to tailor with records, acquisition, and technology personnel. They do not establish the schedule or record status of a particular program artifact.

Together, these sources support a bounded conclusion: public digital information should be authoritative, usable, accessible, interoperable where appropriate, controlled through its lifecycle, and accountable to named owners. They do not say that all channels should expose the same fields or that one computational model can resolve legal interpretation, notice, privacy, records, and due process by itself.

One rule means one governed semantic revision

The phrase “one program rule” can mislead if it suggests that a complex program has only one formula. The governed object may contain many related elements:

• Source authorities, policy interpretations, definitions, and owners
• Facts and evidence requirements, including source, time, and quality
• Calculations, predicates, thresholds, constraints, and approved exceptions
• Effective periods, transition rules, superseded revisions, and case treatment
• Reason codes, explanation elements, and facts that cannot be disclosed
• Roles that may propose, review, approve, determine, correct, or publish
• Output schemas, surface permissions, retention cues, and downstream contracts

Grid proposes packaging those elements as a versioned executable model. A named program owner accepts a specific revision through the organization's actual governance process. Inputs bind to declared sources. The model evaluates only the represented rules. The proposed result record must explicitly carry the source and rule revisions, effective time, status, material reasons, and unresolved evidence used; those business provenance fields do not appear merely because a formula evaluated.

That package becomes a source for audience-specific projections. It is not the legal authority, the complete case record, or the official action by itself. Generated code or language can remain a proposal until qualified owners validate it. A computational result can remain pending until the authorized external process makes a determination.

Five surfaces, five contracts

Alignment does not require sameness. Each surface should declare what it receives, what it may reveal, how it identifies the rule revision, and which obligations remain local.

1. Staff tool

The staff surface may show case facts, evidence gaps, represented calculations, exceptions, internal review state, and next authorized actions. It should distinguish an automated finding from an official determination and expose when policy or evidence requires judgment. Role access, case privacy, separation of duties, and records capture remain program responsibilities.

2. Public explanation

The public surface may explain current definitions, requirements, examples, effective dates, and how to seek help or challenge an outcome. It should use governed language appropriate to its audience without exposing protected facts or internal controls. Plain language, translation, accessibility, and notice sufficiency require qualified review; they cannot be inferred from calculation fidelity.

3. Notice or document

A case-specific notice may combine the accepted result with an approved template, required citations, facts, reasons, deadlines, contact paths, and appeal or reconsideration instructions. The template and the model each need version identity. Producing a complete-looking document does not prove legally adequate notice, valid service, or satisfaction of due process.

4. Report or dashboard

An aggregate report needs stable definitions, time windows, inclusion and exclusion rules, revision history, suppression and privacy controls, and reconciliation to the records it summarizes. A report can use the same semantic definitions while intentionally omitting case-level detail. Changing a program rule may require restating a series or preserving the old definition for historical comparison rather than silently recalculating the past.

5. Configured API

An API should publish typed fields, status and reason semantics, effective and model revisions, error behavior, correction rules, and a compatibility policy. Consumers may receive a result or public rule description without receiving the entire model or source record. Interface documentation and conformance tests are necessary; an available endpoint does not establish authorization to disclose its content or compel a partner to accept it.

Govern the change, not only the current answer

A program change begins before deployment. The source may be legislation, regulation, appropriation, policy, approved interpretation, administrative correction, or time-bound emergency direction. The responsible owner must identify what changed, who may interpret and approve it, when it takes effect, which pending and historical cases it affects, and what notice or public process is required.

In the proposed pattern, the change is authored in a branch with its source and rationale. Known cases and boundary conditions are replayed. Surface owners review the new explanations, templates, report definitions, and API contract. Accessibility, privacy, security, records, fiscal, legal, and program authorities perform their actual reviews. The approved package receives an effective interval. Older revisions remain reconstructable under the applicable retention rules.

Rollback is also governed. Reverting software does not automatically reverse a determination, restore a spent appropriation, withdraw a notice, correct a partner's cached result, or decide how an appeal should be handled. Those are program actions with their own authorities and receipts.

A fictional multi-surface change

Consider the fictional Northbridge Emergency Repair Grant. This is an authored exercise, not a real program, legal interpretation, funding recommendation, or benefit system.

Revision N-006 represents three aggregate requirements: an application received by a declared cutoff, a residence inside a fictional incident zone, and an expense type on an approved list. It calculates a proposed grant as the lesser of a stated percentage of verified eligible cost or a fictional cap, subject to represented remaining funds. Staff still must review evidence and exceptions, and an authorized external process must issue any determination.

The exercise begins with five copies. A staff application contains N-006. A public FAQ repeats its cap and expense list. A notice template carries three reason phrases. A monthly report embeds the eligible-expense definition. A partner API returns represented_eligible without a model revision.

Revision N-007 adds one fictional expense category and raises the cap for applications received on or after 09:00 on September 1. Updating only the staff tool produces predictable divergence: the FAQ understates the current cap, the notice lacks a reason for the new expense, the report mixes definitions, and the partner cannot tell which rule produced its result.

Under the Grid proposition, each test case binds to N-006 or N-007 by effective time. The staff view shows evidence and review state. The public explanation resolves the current general rule and its effective date. The notice surface maps a represented reason code to a separately approved template. The report carries the definition revision for each aggregate. The API returns a typed status, reason code, and model revision.

The exercise proves none of those statements about a live program. It simply gives an evaluator an oracle: which revision should apply, what each surface may show, and which artifacts should change when one governed rule changes.

Evaluate semantic alignment with failure cases

Begin by inventorying every current implementation of the selected program rule: applications, formulas, scripts, web copy, PDFs, call-center material, report queries, interfaces, manual workarounds, and local interpretations. Record their owners, revisions, change effort, known disagreements, correction history, and the time required to reconstruct a sampled decision.

Before configuring Grid, have qualified owners approve a small set of expected cases. Include clean cases, effective-time boundaries, missing and conflicting facts, an exception, exhausted represented funds, a corrected source, and a case that must remain unresolved. Then inject surface failures: a stale cache, an old API consumer, an unreviewed translation, an inaccessible document, a notice missing a reason, a report using the superseded definition, an unauthorized override, and a failed records capture.

Measure at least six layers:

• Semantic fidelity: expected calculation and disposition for each approved case; deterministic replay against the same source and model revisions; no unsupported final determination.
• Cross-surface alignment: every output identifies or can be traced to its semantic revision; expected differences are authorized; unintended disagreements and stale projections are detected.
• Change control: elapsed time and manual handoffs from accepted policy change to reviewed surfaces; boundary cases replayed; approvals, effective dates, migrations, and rollback limitations retained.
• Explanation quality: public and staff reviewers can identify the applicable rule, material facts, reason, missing evidence, next step, and what the system cannot decide.
• Interface and access behavior: typed contract tests pass; incompatible consumers fail visibly; disclosure is restricted as configured; accessibility is evaluated on each actual surface under the applicable standard and test process.
• Records and authority: required artifacts are captured with metadata; previous decisions can be reconstructed; proposed, approved, published, and determined states remain distinguishable; unauthorized actions are blocked in the tested boundary.

Set thresholds before running the fixture. Treat a wrong revision at an effective-time boundary, an unsupported determination, a hidden interface failure, or a required inaccessible surface as a failed evaluation rather than averaging it into a composite score.

A passing fictional fixture supports, at most, a product-demonstration claim for those declared cases, surfaces, versions, and conditions. Customer-controlled testing must establish behavior with the program's actual sources, rules, users, integrations, security controls, and governance. Legal sufficiency, Section 508 conformance, records compliance, privacy, fiscal authority, service quality, and public outcomes each require their own responsible evaluation.

The Policy That Can Explain Itself paper applies the authority boundary to eligibility, exceptions, notices, and appeal. From a Spreadsheet to a Shared Model shows how private implementations can become shared infrastructure, while the readiness assessment helps define ownership and acceptance evidence. Implementation teams can continue with canonical Grid examples.

The objective is not one screen and not one indiscriminate data store. It is one governed semantic revision, projected through many accountable surfaces, so a program can change its rule without losing track of which answer it gave, to whom, under whose authority, and why.