The Shift

There’s been a quiet shift lately in how people evaluate technology. Across systems like grants management, benefits enrollment, healthcare access, and tax filing, it’s no longer just does it work or is it fast enough.

The real question is much sharper:

"CAN I TRUST IT?"

For any organization building systems today, especially in government and public-service contexts, this question operates at the core of delivery and decision-making. The level of trust users have in the software directly shapes outcomes and is increasingly serving as a differentiator.

That idea has shaped how we have built at Tactile for years.

During one grant management project, our team faced a familiar choice. We could streamline the experience by hiding some of the complexity behind the scenes, or we could make the process more transparent, even if it meant exposing additional information, statuses, and decision points to users.

We chose transparency.

The result was not just fewer support questions. Program staff spent less time trying to understand what the system was doing because the system explained itself. Users could see where they were in the process, what actions were required, and why decisions were being made.

Visibility created confidence. People understood how the system worked, so they trusted it. But transparency was not simply a user experience decision. It was a system design decision. All the workflows, permissions, data, statuses, and interfaces had to support it. That distinction matters because trust is not something we communicate after a system is built. It is something we engineer into the system.

Trust Is An Architectural Property

You can usually spot the problem in the software itself.

We see this in software all the time, a form that asks for data without explaining why, or an error message that tells you nothing, or has no context behind it? The system technically works, but it feels like a black box.

That is what happens when teams build to get through a compliance review instead of building for the person on the other side of the screen.

When we build like that, ethics and privacy show up late. They become checklists, approvals, and sign-offs right before release. The system passes. It ships. And users are left trying to figure out what just happened.

Our alternative is to turn principles into architecture. Privacy should influence what data we collect and retain. Accountability should influence permissions and audit trails. Transparency should influence workflows and interfaces. Human oversight should influence what a system is allowed to do on its own.

If a principle never changes how the system is designed, it is difficult to argue that the principle is actually being enforced.

Trust shows up much earlier than most teams expect. It’s in the way the software behaves when someone is actually using it. How the system asks for information. Whether it explains what it’s doing. The messages displayed when something breaks.

The small moments are what people remember. When the system asks for data, does it tell you why? When a decision is made, does the system show its work? When something doesn’t fit the normal path, does it help you recover or leave you stuck?

People pick up on this fast. They may not articulate it in words, but they feel it.

“If a user has to guess what we’re doing with their data, we’ve already introduced a risk we didn’t need.” — Joe Kucharski, Project Director

From Principles to Public Trust

A useful way to think about this is as a progression: Principles → Controls → Evidence → Trust.

Principles define what we value: privacy, fairness, transparency, and accountability. Controls translate those values into permissions, policies, validation rules, decision boundaries, and human review. Evidence demonstrates that those controls are actually working through logs, lineage, monitoring, versioning, and auditability.

Trust is the outcome. Stakeholders do not have to simply take our word for it. They can see how the system operates and verify that it is behaving as intended.

Security plays a role here as well, but protecting data starts before encryption, access controls, and audit logs. It starts by asking whether we should collect the information at all. What purpose does it serve? Who actually needs access to it? How long should we retain it? Can we accomplish the same objective without it?

Encryption and access controls protect the data we have. Responsible architecture also minimizes the data we need to protect in the first place. Privacy should be the default condition of the system, not something added after the architecture has already been decided.

The Front-Page Test

Strong systems hold up under scrutiny and real-world use. The practical test is simple. Imagine your system’s behavior published on the front page of the website, with data handling, decision logic, and obscure user behavior all laid out in plain view. Would you stand behind it without qualification?

Make this operational with a simple rule teams can repeat:

In practice, if you wouldn’t defend it publicly, don’t ship it privately.

The Front-Page Test tells us whether we are willing to defend a decision. Good architecture gives us something equally important: the ability to prove what actually happened. A trustworthy system should be able to answer both questions.

Teams that can answer yes tend to converge on the same priorities. They make decisions explainable. They give users visible control. They remove ambiguity where it matters.

The Internal Revenue Service Direct File pilot reflects this approach. Clear calculations and transparent eligibility rules reduced errors and drove high user satisfaction, with roughly 90 percent of users rating the experience above average and a majority reporting increased trust in the IRS. Trust showed up in how people experienced the system, not just whether they used it. That distinction is where most systems fall apart.

If you look at systems through that lens, you start to notice a pattern.

The Shape of Trustworthy Systems

These principles matter for any public-facing technology, but AI raises the standard. AI systems can introduce probabilistic outputs and decisions influenced by data in ways that are harder for users, and sometimes teams themselves, to inspect.

That creates additional questions. What influenced this output? What information was involved? What is the AI permitted to decide? Where is human review required? And can we reconstruct what happened after the fact?

Trustworthy systems share a recognizable pattern. They signal intent through behavior, they communicate clearly, and they remain consistent over time.

Behavioral signals come first. Users respond to what the system does, not what it claims. Defaults guide decisions. Friction communicates importance. Transparency shows respect.

Security is part of this conversation too. Users rarely evaluate encryption standards or access controls directly. They evaluate whether the system behaves like it takes their information seriously.

You can see this in how the VA has evolved its digital health tools. Through VA.gov, My HealtheVet, and the Blue Button initiative, patients can access their records, download their data, and see more clearly what the system knows about them. That level of visibility was not the easiest path technically, but it changed how people relate to the system. When users can see and move their own data, the system feels less like a black box and more like something they can work with.

Systems that are clear and easy to understand reduce both user error and institutional risk.

The Social Security Administration has steadily expanded its online benefits experience so people can start an application, check where it stands, and finish without calling or visiting an office. When users can complete these steps directly online, satisfaction is higher and fewer people need to seek help mid-process. When the experience is unclear, people drop out or turn to support channels instead.

Consistency is what sustains trust. Teams are under pressure from deadlines, funding constraints, and policy shifts. The systems that hold their standards in edge cases and under stress build durable confidence over time.

AI is now part of this story, whether teams acknowledge it or not. You see it in fraud detection models, eligibility scoring, and case prioritization systems running behind the scenes. These systems flag risk, rank applications, and shape outcomes in ways users cannot always see. That changes the bar.

When AI influences eligibility, prioritization, or fraud detection, people expect more than accuracy. They want to know if it is there. They want to understand what it is using. And they want a clear path to question or correct it.

Increasingly, AI is doing more than evaluating outcomes. It helps people avoid problems before they happen. A grants manager might receive a warning that required documentation is missing before submission. A program officer might be alerted to potential compliance risks before a review begins. Instead of simply making decisions, the system helps people make better decisions themselves.

This reflects an important boundary: AI can assist, but people and institutions remain accountable. That does not mean every AI action requires manual approval. The appropriate level of autonomy should reflect the risk of the decision. But accountability cannot simply be delegated to a model because the model participated in the process.

That shift matters. People are no longer judging AI solely by the decisions it makes. They are judging it by whether it helps them navigate the process with more confidence, clarity, and control. When AI helps people understand what is happening, what needs attention, and what action they can take next, it reinforces trust. When that visibility is missing, trust drops off a cliff. When it is present and grounded in clear boundaries and accountability, trust holds.

“Consistency is what makes trust durable. One exception for speed or convenience creates a precedent the system has to carry forever.” — Jim Kiley-Zufelt, Vice President and COO

Trust Has to Survive Production

Responsible design does not end when a system launches. Models change. Data changes. Policies change. User behavior changes. Systems that were operating appropriately six months ago may behave differently today.

That makes monitoring, model and configuration versioning, audit trails, incident response, and periodic review part of the trust architecture. The question is not simply whether we trusted the system when we deployed it. The question is whether we can continue producing evidence that it deserves that trust.

Ultimately, public trust in AI is not created by publishing principles or promising responsible behavior. It comes from systems that make those principles enforceable and observable.

Principles become controls. Controls produce evidence. Evidence earns trust.

That is what it means to build a system you can stand behind.

Many types of organizations can absorb a loss of trust. In government systems, the consequences of getting this wrong are much harder to contain.