Give AI responsibility
without giving up control.

Vera sits between the AI your team already uses and the systems your business runs on. It decides what AI is allowed to change, and keeps the evidence of what actually happened.

The problem

AI has started doing the work, not just describing it.

Updating records. Changing documents. Sending messages. Modifying code. Running processes that used to need a person.

That is a different problem from getting a good answer. Once AI can change things, somebody has to decide how much authority it gets, and somebody has to be able to check the work.

How do you give AI enough authority to be useful, without simply trusting whatever it says it did?

Most teams answer that today by keeping AI on a short leash and checking everything by hand. That works until the volume grows, and then it quietly stops working.

Where Vera sits

Vera is not another AI.

Claude, ChatGPT, Gemini and whatever comes next supply the intelligence, and they will keep getting better without any help from us. Vera is the layer underneath, where a decision turns into a change in your business.

Your AI Claude · ChatGPT · Gemini · agents
Vera Know · Control · Verify
Your company Documents · email · code · business systems

Vera runs today against Google Workspace. Other business systems are in development. See what we are building.

What Vera does

Three jobs, in the order they matter.

01

Know: AI should work from the right information

Company information changes constantly. Policies get replaced, decisions get made, projects change direction. The old documents stay in Drive looking exactly as official as the new ones. AI cannot usually tell the difference, and it will answer from the wrong one with complete confidence.

Vera marks which information the company treats as current and which is history, and every answer carries where it came from: the file, the folder, when it last changed and when Vera last read it. Ask what the priorities are and you get the current ones. Ask what was decided in December and you get December.

Today this works over information the company has organised for it. Vera does not yet resolve contradictions between sources on its own, and does not pretend to.

02

Control: AI should only change what you allow

Access mattered less when AI only read things. It matters a great deal once AI can write. The question stops being "what can it see" and becomes "what is it allowed to do, and to which exact thing."

In Vera, every automated change is declared in advance. Which system, which part of it, and which process owns that. Anything not on the list does not run. Something unrecognised stops the job rather than quietly slipping through as an exception.

This runs in production for Vera's own operations. Extending it to a general boundary across a customer's systems is the architecture we are building next.

03

Verify: do not trust “done”

A success message is not proof. Systems accept requests they only partly carry out, and report success anyway. If nobody checks, the gap between what was intended and what actually happened just sits there, silently, until it turns up in a decision.

Before Vera changes anything it confirms it is pointed at the right thing, not a similarly named one. Afterwards it compares what it meant to do against what the system reports it did, and refuses to record success when those disagree.

Vera records how strong each check was, rather than treating every confirmation as equally good. Today most checks rest on what the target system reports about itself, which is a real check and a weaker one than reading the result back independently. We would rather say which we did.

Why we built it this way

We learned this by getting it wrong ourselves.

One of our own automated processes updated a management workbook every fifteen minutes. It ran roughly eleven thousand six hundred times across a hundred and twenty-one days, and reported success every time.

It had been writing to the wrong file since April.

Separately, an operation set out to update twenty-four cells. The request was accepted. Fourteen of them were saved. That was reported as a success too.

Nothing crashed. Nothing went offline. No alert fired, because from the outside everything looked fine, which is precisely what made it dangerous. Wrong information sat in a management workbook for four months and was used.

That is the kind of failure that gets considerably more serious when AI is the thing taking the action. So we rebuilt around one rule:

Permission to attempt something is not proof that it happened correctly.

Running today

This is not a prototype we are describing.

Vera runs Digital Galactica Labs' own operations. Not a pilot, not a demo environment. The real thing, with real consequences when it is wrong.

31governed operations, every 15 minutes, unattended
2independent checks that it is pointed at the right target, before writing
0changes recorded as successful without passing their check

Every figure here is checked against the running system rather than estimated.

Honestly, where this is

What is built, and what is being built.

Vera is Digital Galactica Labs' production operating system and its proving ground. Everything described above runs there, against real data and real operations. That is why we can describe it in this much detail.

The commercial platform is being built. These are not available today, and we are not going to imply otherwise:

  • multi-company use, with proper separation between customers
  • enforced customer sign-in and access control
  • a broad catalogue of connected business systems
  • the general boundary through which any AI tool's actions would pass
  • automatic resolution of contradictory company information
  • verification extended across every business system rather than the ones proven so far

If the problem at the top of this page is one you recognise, we would like to hear how you have it. That conversation is useful to us whether or not you ever become a customer.

Talk to DGL

For technical evaluators

How it actually works.

In one line: AI decides what should happen. Vera controls whether it may happen, and records the evidence of what actually did.

Governed execution

Actions are declared, scoped to an exact resource, and authorised per principal before execution. An unrecognised target fails the operation rather than defaulting to allow.

Target identity verification

The resource is independently identified before a write, by identifier and by name, because a valid identifier for the wrong system is exactly how our own failure happened.

Result verification, graded

Evidence records its own basis: version and precondition checks, independent read-back, or the target system's self-report. These are different strengths of claim and are stored as different strengths.

Idempotency and preconditions

Intents carry an idempotency key so a retry cannot execute twice, and use version or If-Match preconditions where a system supports them, so a concurrent change fails the write rather than silently overwriting it.

Evidence trail

Each operation appends what was attempted, against what, by which process, how long it took and how it was verified. Reconstruction after the fact does not depend on memory.

Model independence

Vera is a resource AI clients connect to over standard authorisation, not a wrapper around one vendor's model. Changing which AI does the thinking does not change the controls or the record.

Some of the above is running in production for Vera's own operations and some is the architecture the commercial platform is being built on. We are happy to walk through which is which in detail. Just ask.