Compliance analysis that shows its work, and says where it stopped.
Rote reads the documents a compliance program already has, policies, vendor agreements, risk documentation, against the regulation that governs them. Each finding comes back with the provision it was read against and the passage it came from. So does the other list: what the documents did not answer. Both halves are the point. A finding that carries its source is one that survives a client, an assessor or a board without being rebuilt to defend it.
Two things live here, and they are not the same thing. The method is published: 13 skills you open, change and run yourself, under Apache 2.0. The software that runs those skills across a whole workspace is the instrument behind one practice, and it is not open for signups. Each section below says which of the two it is describing.
The person who has to sign the finding.
Rote is built for whoever is accountable for the answer, not for whoever is available to do the reading. Four situations account for most of the people who end up here.
An independent compliance consultant or fractional officer running several client engagements at once. The reading is the same work every time and the judgment is different every time. A run hands back a first pass with the citations already attached, so the hours go to the conversation about what the finding means.
A compliance or privacy officer whose program has grown past what one person can re-read in a year. Policies, agreements, training records and vendor relationships all have to be checked against the same rule. A run produces the coverage map, and names the questions it could not answer from the documents alone.
A healthtech company or vendor with a contract waiting while a buyer’s security team works through forty questions that presume a risk analysis, a risk register, a training log and a BAA posture. The artifacts that answer them have to hold up for the next buyer too.
Staff are pasting work into chatbots, a vendor switched on an AI feature inside a system that touches ePHI, and what is allowed has not been written down yet. OCR expects the risk analysis to cover that surface, which means the inventory comes first.
Four things, and a client can see all four.
The output is built to be handed on. Every skill in the library returns the same four things, whatever it was pointed at, and that holds whether you run the skill yourself or an agent on the platform runs it against a workspace.
- A finding with the citation attached
Not “the policy is thin on access controls” but the control, the provision it comes from, and the passage in your document that did or did not satisfy it. The three travel together, so nobody downstream has to reconstruct the reasoning.
- A coverage map across the rule
Every requirement in scope, marked as covered, partial or absent, with a confidence score against each one. It comes back as a table because a table is what the next meeting needs.
- What could not be determined
The separate list of questions your documents did not answer. A skill says so rather than filling the gap with an inference, and that restraint is what makes the rest of the output safe to rely on.
- A reading anyone can re-run
The file that produced the finding is published. A client, a consultant on the other side of the table, or an assessor can run the same skill against the same documents and get the same result. Nothing rests on trusting the tool.
None of it decides anything. A skill will report that an integration holds mail-read scope with no agreement on file, and cite the provision that makes it matter. Whether that is a Tuesday problem or a stop-everything problem is a call a person makes. What changes is where the hours go: to weighing findings, rather than to the document hunt that produces them.
Read it, change it, run it.
Each skill is one file you can open. It states what it checks, which provision it checks against, and what it refuses to conclude, and the regulatory text it reads against travels inside the file. Reading the whole thing before trusting it with a client's documents takes about ten minutes, and that is the design: nothing about the analysis sits behind a product you have to take on faith.
Changing it is the other half. Reweight what matters for a particular engagement, add what your organization knows that no published file could, cut what does not apply. Apache 2.0. Install from ClawHub, run them together as a Claude Code plugin, or paste one into any model that follows structured instructions.
The library is not a fixed set. Skills are added as the regulations and the work change, and each one is a structured workflow grounded in a named regulation or framework rather than a general-purpose prompt.
The distinction runs through the whole site, so it is worth stating once in one place. One of these is yours to take today. The other is not for sale here.
Every skill is published under Apache 2.0 and free to read. Run them in your own environment, against your own documents, on whatever model you already use. Change what does not fit before you trust it with a client's files.
Browse the library Dan runs it· inside an engagementThe same skills, run by a set of agents against a configured workspace instead of one document at a time. It is the instrument behind the practice rather than a product sold here, it is not open for signups, and access is arranged inside an engagement.
How it worksThe same method, pointed at the field.
Claiming that a reading is checkable is easy. The Part 2 Notice Study is that claim under load: it reads publicly posted patient notices against the 2024 Part 2 final rule and reports what share of a sampled population still describes the old regime. It runs on one of the published skills, on documents nobody selected in advance, so a reader can re-run the reading against the same source rather than take the finding on trust.
Findings are aggregate and name no organization. They report what a public document says, never how an organization operates. The same sampling frame is re-read on a cadence, so each release reports the movement as well as the level.
A fleet of agents.
The same library of skills.
Run by hand, a skill reads one document at a time. The platform puts a set of agents over the same library instead, against a configured workspace: an intake conversation sets the org type and the framework, then gap analysis, BAA review, policy analysis, risk assessment, framework mapping and portfolio review each run on command across the whole corpus, every finding cited to the provision it was read against. Which agents run depends on what has to be demonstrated and to whom. Between runs, a regulatory watch matches Federal Register activity to the sections of a manual by CFR citation.
Not currently open for signups. It runs as the instrument behind the practice that uses it, and access is arranged inside an engagement.
The method is one practitioner's, written down.
Rote is built by Dan Gonzalez, a JD with a Health Law Certificate who built healthcare compliance programs inside regulated technology companies before any of this was software: HITRUST certifications, SOC 2 audits, CMS authorization, BAA review at scale. That is why the skills cite provisions rather than gesturing at frameworks, and why they say what they cannot conclude.
The method and the software are here. The engagements are at dangssolutions.com.
Need this done rather than explained? Dan Gonzalez runs Dang's Solutions, the practice that delivers it.