Skip to main content
Document sign-off

Controlled documents, signed by the right people, with a history an auditor can follow.

A named reviewer and a named approver on every document. Nobody signs off their own work. Every version keeps a record, and if anyone changes it later, it shows.

In early use, with one design partner, a regulated software company.

The problem

The auditor asks who approved this version, and the answer is a search.

  • The quality system lives in a wiki and an inbox.
  • The approver is the author.
  • Version history is a filename.
  • Nobody can show that the approved version is the one still in the folder.
  • The evidence exists, but assembling it takes a week of somebody senior.

A signature is only worth what it was signed against. This binds the two together.

How we work

In. Build. Leave. Prove.

One job, four weeks, in production. Then it keeps proving itself.

  1. In

    Your documents, your roles, and who may review and who may approve.

  2. Build

    We ingest the set and wire the review flow to where your team already writes.

  3. Leave

    Your team reviews and approves in it. Approval is blocked unless verification passes.

  4. Prove

    Every version keeps who reviewed, who approved, when, and what they signed.

What we build

What you get.

  • Your document set under review and approval, with named people on both sides.
  • Roles enforced: the reviewer is never the approver, and nobody approves their own work.
  • A signed history per version, showing name, time and what was signed.
  • Verification that re-checks the approved content, so a later change shows.
  • An export an auditor can read.
Built for the regulator's questions

Who approved this version, on what evidence, and has it changed since?

  1. What the AI is allowed to do is written down first.

  2. Every decision is checked against those rules before it happens.

  3. A named person signs it off. The check produces the evidence; a person judges.

  4. You can replay the whole history any day and get the same answer.

  5. If anyone changes it later, it shows. Patent pending, UK application GB2620101.2.

Your record, as it will look. Example record: Aurora Banking is not a customer.

That is what a deployment leaves running for your job, and what the record holds. In the accessibility product today, a person on your team accepts every finding before it reaches your record.

Who this is for

Who this is for.

  • Medtech and other regulated software teams with a quality system to keep.
  • Teams whose notified body, auditor or customer asks for approval history.
  • Quality managers who assemble evidence by hand today.

Not for

General document storage. This is the sign-off, not the filing cabinet.

Why us

Who you deal with.

You deal with Simon and Jason from the first call. One engineer sits inside your team, full time, for the four weeks.

Simon Milner, Founding Architect

He designed the record: what the AI is allowed to do, checked before it acts, and replayable afterwards. Twenty-five years in Silicon Valley before that.

Jason Crispin, Founder

He owns the customer side of a deployment: what the job is, what it is worth, and that it lands. He is on the first call and every one after.

Meet the team

Questions

What people ask.

Is this a quality management system?

Is this a quality management system?

It is the sign-off and record layer of one. It holds who reviewed a document, who approved it, when, and what exactly they signed. It does not try to be your whole quality system.

What does “in early use” mean for us?

What does “in early use” mean for us?

One regulated software company runs its controlled documents through it today. The review and approval flow, the roles and the signed history are live. What is not built yet we tell you on the call, and we set it up with you rather than leaving you to it.

How long does it take, and what does our team do?

How long does it take, and what does our team do?

You bring the document set and name who may review and who may approve. We ingest the set and wire the review flow to where your team already writes. Your team's part is the reviewing and approving they do today, now in a fixed order with a record.

Does it replace our wiki or the tool we use now?

Does it replace our wiki or the tool we use now?

No. You keep writing where you write. What changes is that a version is reviewed and approved by named people, and the approved version is bound to its content, so a later change shows.

Who can approve, and can anyone get round it?

Who can approve, and can anyone get round it?

Only the people you name. The reviewer is never the approver and nobody approves their own work. Approval is refused unless the latest verification passes, and an edit made outside the process shows.

Can our auditor or notified body see it?

Can our auditor or notified body see it?

You can show the history for any version: who reviewed, who approved, when, and whether the content still matches what was signed. There is no separate external login today, so you show it with them in the room, or export it.

Where are the documents kept, and who at AUDITSU can see them?

Where are the documents kept, and who at AUDITSU can see them?

In your AUDITSU account, with access limited to the people you name. What we hold, where, and how it is protected is on the security page. We do not read your documents to run the service.

What does it cost, and what happens after?

What does it cost, and what happens after?

Scoped on the call, then a monthly subscription for the sign-off and the record on AUDITSU. Once it is running your team reviews and approves in it and the record builds itself, and you can export the history at any time.

Want to see it on your own documents?

Thirty minutes with Simon and Jason. Bring the document set and the question your auditor asks, and we will tell you what it would take.