Fidé: a continuous watch for the policies no auditor certifies

The policies nobody certifies

When a customer asks whether you're compliant, they're usually asking about a standard. SOC 2 for your controls, ISO 27001 for your security program, HIPAA if you touch health data. Those come with auditors, tooling, and a certificate at the end, and they're the smallest part of the picture. The organizations I've worked with (a law firm and a fintech among them) ran on layers of policy that no certificate covers: internal standards, government regulations specific to their sector, and expectations written into customer contracts. Fidé, the prototype this post walks through, came out of one of our design sprints and aims at exactly that layer. To be plain about what it is: an interactive design argument you can click through, not software anyone runs today.

Two examples show the range. An engineering org decides that every repository must carry a pre-commit config with a specific set of hooks. That's a policy, and someone is supposed to verify it on every repo. A facilities team keeps a standard for what the cafeteria kitchen must stock and how it's maintained. That's a policy too, with a checklist and a person responsible. Code on one end, kitchens on the other, and in between: onboarding steps, access reviews, records retention, vendor requirements. Most of what a company has to enforce looks like this, and none of it comes with an auditor. First we look at why the compliance platforms don't reach this layer, then at Fidé's object model, then at what changes when the checking runs continuously.

Why you can't buy this

The certification side is well served, and the platforms are broader than their reputation. Vanta automates evidence collection across 35+ shared security and privacy frameworks and lets you define custom frameworks and controls [1]. Drata goes further: you can import your own requirements as a custom framework, map its automated tests to a custom control, and even push data from your own systems into custom tests [2]. So the honest version of the category's promise is "bring your own framework," and it's real. The limit sits one layer down. Automation, in these products, means a library of pre-built tests run against standard integrations, and a control the vendor has no test or integration for falls back to manual evidence: a file upload, a screenshot, a ticket [3]. Your pre-commit rule and your kitchen standard land in exactly that bucket, because no shared test library can anticipate policy that's yours alone.

So internal policy gets enforced the way it always has been: a wiki page, a spreadsheet, an occasional reminder email, and the diligence of whoever cares most. IT operations usually ends up as the strongest enforcer in the building, because it can codify its rules directly into software through device management and access provisioning. Everything IT doesn't touch runs on the honor system. That gap, an enterprise-wide way to define your own policies and know they're being followed, is the problem Fidé explores.

Controls, checklists, targets

Fidé's design starts from the object model rather than the screens. A control is a single checkable statement: this repo has the required pre-commit hooks, this entity filed its quarterly attestation, this new hire completed security training. Controls group into checklists, which is where a policy lives. A checklist gets applied to targets: the set of repositories, the list of legal entities, this quarter's new hires. Agents keep each check current, re-verifying on a cadence and updating status without anyone asking. The operational question shifts from "when did we last check?" to "which targets are failing right now?"

The main screen flattens all of that into one list, one row per target, each row carrying its live status. In the demo data (placeholder numbers, but the right shape) the filter chips across the top read All 24, Failing 13, Attention 4, Due 6, Complete 1: the whole program in one line, with the failing targets sorted to the top. A legal entity on a quarterly financial-controls checklist sits above source repositories held to a repo baseline, which sit above new hires moving through onboarding. Three departments, one list, because from the program's point of view they're the same kind of object: a target that's either current or overdue for someone's attention.

Two hard problems sit under this design, and a real build would live or die on them: false alarms and ownership. Ownership is the simpler one. A failing target only gets fixed if a name is attached to it, which is what the prototype's team-and-roles surface is for. False alarms shaped the status vocabulary itself, and that decision earns its own paragraph at the close of this post.

From quarterly reconstruction to a continuous watch

Compare that with how the same program runs today. A deadline lands: a board review, an external audit, a regulator's request. Someone reopens last quarter's spreadsheet, emails a dozen owners for fresh evidence, and spends three days rebuilding a snapshot of a world that kept moving the entire time they were assembling it. By the time the snapshot is done, it's already slightly wrong.

The difference is easiest to see on a timeline.

Same issues, same timeline. In the quarterly model an issue waits, unseen, for the next check; under a continuous watch it surfaces when it occurs. Schematic illustration; the levels carry no data.

Between quarterly checks the state of every policy is unknown, and problems accumulate in the dark: a repo drops a required hook, an onboarding stalls, a control lapses. With agents doing the verification continuously, the same problems still occur, and they stay the same size. What changes is when you find out: early, while the problem is still one repo or one stalled onboarding instead of a quarter's worth of drift.

The payoff shows up when someone checks your work. In an external audit the evidence is already assembled, because assembling evidence is what the agents have been doing all along. In an internal review, "where do we stand?" has a current answer instead of a project attached to it. And because issues get caught when they occur, the organization operates closer to its own written standards over time, which is worth more in front of a regulator, or a big customer's security team, than any binder assembled the week before.

The screen is a list of what's wrong right now

Every compliance tool on the market is built around an event (the audit, the board review, the renewal) because a human did the checking, and a human can only check at intervals. Fidé hands the checking to agents and has no event at its center. This is the inversion our design-sprint essay traces through all fourteen prototypes: the person's job moves from doing the verification to supervising a watch that never stops. What makes it possible is that an agent can be pointed at your rule (read this repo's pre-commit config, this entity's filing, this hire's training record) without a vendor building an integration first. The screen a supervisor lives in is then the obvious one: a list of what's wrong right now, not a report assembled for an event. And the supervisor keeps the two calls that stay human: deciding what a rule actually means, and who owns fixing a breach.

List the policies no system checks today

What Fidé is, honestly: a prototype from one of our design sprints. Nobody is running their compliance program on it today; its job is to make a design argument concrete. And it's a working example of the model we describe in bespoke SaaS, because a policy platform is only worth having if it's shaped to your organization's own rules, and that's software you have built for you.

One design decision follows directly from the watch being machine-run, and it's the one I'd defend hardest: Attention and Failing are separate states on purpose. When a person assembled the status, they hedged it in the email that delivered it. When an agent produces it, the meaning of red becomes a contract the software has to keep. Let one renamed rule masquerade as a failure and the supervisor learns to discount the color, and then the watch is worthless.

The practical place to start, whether or not you ever build anything: list the policies your organization enforces that no system checks today. The pre-commit configs. The onboarding steps that stall silently. The quarterly attestation someone tracks in a spreadsheet. The kitchen standard, if you have one. It was a long list everywhere we looked, so a long list is normal. Take the list to your next ops review, pick the three policies you'd want under watch first, and name who triages what the watch turns up. If you want to compare notes on the list, we're at [email protected].