A public-facing civil system with a model inside it is held to a different standard than an internal tool, and the difference is not technical. It is that the people affected by the output can see it, are entitled to understand it, and can contest it. That single fact drags in accessibility, plain language, privacy, notice, appeal, records and documentation obligations that most machine learning teams have never worked under. It also changes the delivery plan, because these are not review items to clear at the end. They are design constraints that decide the architecture. This is written for the delivery lead who is accountable for a system the public will use, and who would rather find the problems before the agency's oversight staff do.
The pattern that hurts is familiar. A capable team builds a working model, the demonstration goes well, the customer is pleased, and then the system meets the agency's accessibility review, privacy office, records officer and public affairs shop in sequence over four months. Each finds real issues. Each issue is cheap in design and expensive in a built system. The schedule absorbs the first two and the program absorbs the rest. Nothing in that sequence was unpredictable, which is what makes it worth engineering around.
What "public-facing" actually changes
Five obligations arrive together on a civil system that touches the public, and they interact.
Accessibility. Federal agencies must make electronic and information technology accessible to people with disabilities under Section 508 of the Rehabilitation Act, and the Access Board's standards incorporate the Web Content Accessibility Guidelines. This is not a checklist applied to finished screens. Model-driven interfaces create new patterns that guidelines were not written against: results that update without a page load, confidence displays, chat surfaces, and content generated at runtime that no one wrote or reviewed.
Plain language. Federal agencies are required to write public communications in plain language. When a model produces the words, the requirement lands on the generation and the templates, not on a copywriter at the end.
Privacy. A system holding records about identifiable people brings the agency's privacy machinery with it: a privacy impact assessment, and where records are retrieved by personal identifier, a system of records notice under the Privacy Act. Both take calendar time and both ask questions about data flows that the engineering team is the only party able to answer.
Notice and contestability. When a model contributes to a decision about a person, the person generally needs to know a decision was made, on what basis in terms they can understand, and how to challenge it. That reaches into the data model, because you cannot explain a decision you did not record.
Records. Federal records requirements apply to what the system creates. If the system generates correspondence or determinations, those are records with retention obligations, and retention has to be designed rather than discovered.
Public-trust obligations by cost of retrofitting after the build
Editorial weighting, illustrative rather than measured. The last row is deliberately low: static styling is the one item that genuinely is cheap to fix late.
Accessibility for interfaces a model drives
Most accessibility guidance assumes pages authored by a person. Model-driven interfaces break three of those assumptions, and the fixes are specific.
Content that arrives without a page load. When results stream in or a status changes, a screen reader user gets nothing unless the region is announced. That means live regions with the right politeness setting, a single announcement rather than one per token, and focus that does not jump while someone is reading. Streaming output is the most common failure we find, because it is invisible to a sighted tester and obvious within ten seconds to a screen reader user.
Confidence and uncertainty shown visually. A colored bar or a shaded badge that means "lower confidence" communicates nothing to a person who cannot see color, and often nothing to a person who can. Uncertainty needs a text equivalent stating what it means in the user's terms, not a number the user has no way to calibrate.
Text nobody wrote. Generated content can break heading order, emit tables without headers, produce link text like "click here", or output an unstructured wall of prose. The fix is to constrain generation to a validated structure and to test the rendered output rather than the template. Where a model produces markup, sanitize and normalize it before it reaches the page.
The testing regime matters as much as the design. Automated scanning catches a meaningful minority of issues and is worth running in the build pipeline on every merge, because it stops regressions cheaply. It does not find focus traps in a dynamic flow, an announcement that arrives too late, or a form where the error message is visible but never spoken. Those come from keyboard-only walkthroughs of each user path and from screen reader testing on the real system. Both belong in the sprint, not in a pre-delivery event.
The decision record, which is where explainability really lives
Explainability in a public system is not a feature bolted to the model. It is a data modeling decision made early. If the system cannot reconstruct what it did and why, no amount of interpretability tooling produces an answer a person can rely on months later.
The record that works has a defined shape. A stable decision identifier. The subject of the decision. The timestamp. The version of every component involved: model, prompt or feature definition, business rules, reference data, thresholds, and the code. The exact inputs as they were at decision time, or a reference to an immutable snapshot of them. The output, including any score and the threshold it was compared against. The specific factors that drove the result, captured at decision time rather than reconstructed. Any human review, with the reviewer, the action and any override reason. And the notice that went to the person, stored as sent.
Two design points make this hold up. First, immutability: the record is append-only and versioned, because a decision record that can be edited proves nothing. Second, reproducibility: given the record, the team should be able to rerun the decision and get the same answer. That means pinned model versions and snapshotted reference data, not the current state of a table that has since changed. When an appeal arrives eleven months later, reproducibility is what turns an argument into a lookup.
Retention has to be decided with the agency rather than assumed. The record supports appeal windows, oversight review and audit, so the retention period is a records question with legal input, and it is cheaper to answer before the schema is fixed than after the first year of data exists.
Notice and appeal as a workflow, not a page
A contestability path that works has six parts, and each one is a build item.
Notice, delivered in a channel the person actually uses, in plain language, stating what was decided, the main reasons in terms tied to their own information, and what happens next. Reasons that map to something the person can act on, which means the factor names have to be human categories rather than feature names from the model. A submission path with more than one channel, because a public system that only accepts appeals through a web form excludes people. Evidence handling, so a person can attach what they have and the reviewer sees it next to the decision. A reviewer interface that shows the decision record, the inputs, the factors and the person's submission on one screen, and captures the outcome as structured data. And a feedback loop, where overturned decisions are reviewed as a set, because a cluster of overturns pointing at one factor is the earliest signal that something in the model or the data has shifted.
That last mechanism is the one most often skipped and the most useful. Appeals are free labelled data about the system's errors, produced by the people best positioned to notice them. A program that reads its overturn patterns monthly finds problems long before a monitoring dashboard does.
Privacy engineering, in the terms the privacy office uses
Privacy work goes wrong when it is treated as paperwork produced at the end. The privacy office asks questions that only the engineering team can answer, and the answers are much easier to give if the system was designed with them in mind.
Four practices carry most of the weight. Minimization decided per field, with a written reason for each personal data element the system holds, because "we might need it" does not survive a review and does not survive a breach either. Purpose limits enforced in the access layer rather than stated in a policy, so a rule about a sensitive column is written once and applied everywhere. Separation of the analytic environment from the operational one, with de-identified or restricted data used for development and evaluation. And logging that captures who accessed which record for what reason, since a system holding personal data will eventually be asked exactly that.
On documentation, the useful artifact is a data flow description written by the engineers and readable by a non-engineer: every source, every store, every transfer, every recipient, the legal basis and the retention for each. That document answers most of a privacy impact assessment directly and is the most useful thing a delivery team can produce early. NIST SP 800-53 gives the control vocabulary the agency's security staff will use; mapping the system's actual mechanisms to those control statements while building keeps the accreditation conversation short.
Two review tracks, compared
The difference between building these obligations in and reviewing for them later is best seen side by side.
| Obligation | Handled as an end-stage review | Built in from the first sprint | What the difference costs |
|---|---|---|---|
| Accessibility | Audit findings against finished screens and flows | Patterns chosen for dynamic content; keyboard and screen reader tests in the sprint | Interaction rework, which usually means component rewrites |
| Explainability | Interpretability tooling pointed at a live model | A decision record capturing factors and versions at decision time | A schema change plus backfill that cannot recover the past |
| Notice and appeal | A form and an inbox added near launch | A reviewer workflow with structured outcomes and a feedback loop | Manual case handling absorbed by program staff indefinitely |
| Privacy | Assessment drafted from interviews after the build | Field-level minimization, purpose limits in the access layer, data flow written as built | Weeks of calendar in review, sometimes a redesign of storage |
| Records | Retention discussed after the first year of data | Retention and disposition designed into the store | A migration under a records deadline |
| Plain language | Editing pass over generated text before launch | Constrained templates, readability checks in the test suite | Ongoing editing of output that regenerates every day |
Verification the prime runs before the customer does
The purpose of internal verification is to make sure the agency's reviewers find nothing the delivery team did not already know about. That is achievable, and it is mostly a matter of running the same checks earlier and on a schedule.
Automated accessibility scanning on every merge, failing the build on new violations, which stops regressions from accumulating. A manual keyboard-only walkthrough of each primary user path each sprint, recorded so it can be shown. Screen reader testing on the actual system rather than on a component library, at least on every path that touches a decision or an appeal. A readability measurement on generated text, sampled and tracked over time rather than judged once. An appeal rehearsal, where someone plays an affected member of the public and walks the full path from notice to reviewed outcome, with the team watching where it breaks. A record reproducibility test, where a decision from three months ago is rerun from its stored record and compared. And a documentation review against the agency's own template, done early enough that a missing section is a task rather than a delay.
Each of these produces an artifact. Taken together they are the evidence package that turns a customer review from an examination into a confirmation, and they are also the material a capture team wants when the same customer writes the next requirement.
Verification steps by how much they reduce customer-review risk
Editorial weighting, illustrative rather than measured. The last row is deliberately low: a single late audit finds problems too late to fix cheaply.
Model behavior in public, and the failure modes that matter
The technical risks worth engineering against on a public civil system are narrower than the general discussion suggests.
Confident wrong output presented as fact. The countermeasure is grounding: answers tied to retrieved source material with the source shown, and a refusal path when the material does not support an answer. A system that says it does not know is trusted more than one that guesses well most of the time.
Inconsistent treatment across similar cases. Two people with materially similar facts should get the same result. Test this directly with paired cases rather than assuming it, and measure outcome rates across the groups the agency's policy staff care about, at a cadence, with the results going to a named owner.
Drift in the input population. Public systems see changing inputs as policy, seasons and public behavior change. Monitor input distributions as well as output quality, because input drift arrives first and is the early warning.
Silent degradation after a dependency change. A model provider update, a reference data refresh or a rules change can move behavior without anything appearing to fail. Version pinning plus an evaluation set that runs on every change catches this, and the evaluation set has to include the hard cases and the edge policies rather than a random sample.
Prompt or input manipulation on a public surface. Anything a member of the public can type reaches the model. Input handling, output validation against an expected structure, and strict separation between retrieved content and instructions are the baseline, and they are cheaper to build in than to add.
How we work inside a civil delivery
Precision Federal is a small business engineering firm. We build AI systems, data platforms, cloud infrastructure and full-stack web and mobile applications, and we deliver them into production inside U.S. federal agencies. On a public-facing civil program we work as a specialist subcontractor to the prime, inside the prime's program management, on a scope the prime writes and the customer can see.
The first weeks are consistent. Week one is access, grounding and reading the current system as it is: environments, repositories, the decision path, the data as it actually looks. By the end of week two we deliver a written assessment covering the accessibility state of the current interfaces with the specific findings, the gaps in the decision record against what an appeal would require, the data flow as built, and the documentation the agency will ask for that does not yet exist. Weeks three through eight produce working increments in the program's environment and repositories, with tests in the program's pipeline: the decision record schema and its writer, accessible components for the dynamic surfaces, the reviewer workflow, and the evaluation suite that runs on every change.
The prime keeps everything. The customer relationship stays with the prime. The code, schemas, tests, infrastructure definitions and documentation are delivered into the prime's repositories and assigned to the prime under the subcontract. Our pre-existing tooling is named, carved out and licensed back perpetually so nothing we bring can block a future maintainer. Data handling is written before the first extract: where data may live, who may touch production, and what is destroyed at the end.
Pricing takes one of two shapes. Fixed-price milestones against written acceptance criteria, which suits this work because the criteria are naturally measurable: violations at a stated conformance level, a decision record that passes a reproducibility test, an appeal path walked end to end. Or a committed team at a defined allocation with a written stopping point when the work is exploratory. Key people are named with committed percentages and a substitution path.
The first step is one email with a one-page brief: the system, the decision it affects, the review dates that matter, the environment and who grants access, and the contract instrument. We return a scoped, priced statement of work with acceptance criteria written as tests. No call required.
Bottom line
Accessibility, privacy, notice, appeal and records are not a compliance layer applied to a finished civil system. They are architecture. The decision record determines whether an explanation is possible at all. The interaction patterns determine whether the interface is usable by everyone entitled to use it. The data flow determines how long the privacy review takes. Every one of those is a design choice made in the first weeks and expensive to revisit later. A delivery team that builds them in, verifies them on a schedule and keeps the evidence turns the agency's reviews into confirmations, and arrives at the next requirement with a working example instead of a promise.
Frequently asked questions
The same accessibility obligations as any federal electronic and information technology, applied to patterns the guidelines were not written against. In practice that means announcing content that arrives without a page load, giving uncertainty a text equivalent rather than color alone, keeping focus stable while output streams, and validating the structure of generated content so headings, tables and link text stay usable. Automated scanning belongs in the build pipeline; keyboard and screen reader walkthroughs of each user path belong in the sprint.
By recording the decision rather than by interpreting the model afterward. Store a decision identifier, the subject, the timestamp, the versions of model, prompt, rules, reference data and thresholds, the inputs as they were, the output and the threshold it met, the specific driving factors captured at decision time, any human review, and the notice as sent. Make the record append-only and reproducible, so rerunning it returns the same answer months later. Then express the factors in categories a person can act on.
Notice in a channel the person uses and in plain language, reasons tied to their own information, more than one submission channel so the path does not exclude people, evidence handling that puts the submission next to the decision, a reviewer interface showing the decision record and inputs on one screen with the outcome captured as structured data, and a monthly review of overturned decisions as a set. Overturn clusters are the earliest signal that something in the model or data has shifted.
In the first weeks, because the privacy office asks questions only the engineering team can answer. Decide minimization per field with a written reason for each personal element retained, enforce purpose limits in the access layer rather than in a policy document, separate the analytic environment from the operational one, and log who accessed which record for what reason. Then write the data flow as built: every source, store, transfer and recipient with its retention. That document answers most of an assessment directly.
Run the agency's checks earlier and on a schedule. Automated accessibility scanning failing the build on new violations, a keyboard-only walkthrough of each primary path every sprint, screen reader testing on the real system for any path touching a decision or appeal, readability measured on generated text over time, a rehearsed appeal walked end to end, a reproducibility test rerunning an old decision from its record, and a documentation review against the agency's own template early enough that gaps are tasks rather than delays.