About
I built this because of one organization.
Where it started
If you run a nonprofit, you already know the part I'm about to describe. Global Child Advocates move children out of Tanzanian orphanages and back into safe families. When I met them, their system could hold a fraction of the kids they serve. I'm Braden Peays, and that is why Unify exists.
You've probably got your own version of it. Software somebody else designed, for somebody else's organization, that you have been quietly working around for years. After a while the workaround stops looking like a workaround. It is just how the job is done now, and it is the part nobody thinks to mention.
So we start by asking the people doing the work. They already know where it gets stuck — usually nobody has asked them in a way that goes anywhere. Then we show you where the technology is failing them, and build around what is really there. Sometimes there is nothing worth building, and we will tell you that instead.
The rules we work under
We are a small team, and these are the rules we started with. None of them is an aspiration. Each one is something the software already does, so each one here comes with the thing that makes it true.
- 01
Evidence
Every claim we make about your organization cites the evidence behind it.
The model only ever sees short references to the passages it is allowed to use, so it cannot cite anything else. There is nothing else there to cite. If a reference does not resolve, that item is dropped before it reaches your report, and before we ship a release we run the same check end to end on a test organization, where one broken citation fails the whole thing.
- 02
Your material
Your material is never used to train general-purpose AI models, sold, or used for advertising.
You get a short, named list of every model that will read your material, before we start, and it does not change without us telling you. The list on our privacy page is not typed in by hand. It is generated from what this deployment is actually running, so it cannot quietly go out of date.
- 03
Your staff
Staff are never evaluated. Systems and process only.
Every prompt in the analysis carries the same rule: the subject of a statement is a process, a system, a document or a piece of work, and never a person, under any phrasing. You see who was invited and who finished, and not what anybody said. Before a release we plant a colleague's name in the material and check that it never comes out the other end.
- 04
What we claim
We don't promise savings we haven't measured.
Every recommendation goes to a critic whose only job is to find the reason it is wrong, and a cost nobody has actually measured is one of the things it looks for. You see what it found, sitting next to the recommendation it is about, rather than filed somewhere you would have to ask for.
- 05
Who approves it
A named person reads everything before you see it.
A finished analysis stops and waits. It goes nowhere until somebody signed in under their own name has read it and pressed publish, and that name stays on the decision in a log we add to and do not edit. Whatever the confidentiality check held back stays held back when they press it.
- 06
Building nothing
We keep what already works.
Doing nothing yet is a real outcome here, and the part of the system that writes recommendations is told it is often the best one. One person describing a problem is a reason to go and ask a second person. It is not a reason to sell you software.
If you're the one who has to say yes
Those are the short versions. There is a longer one written to be forwarded — to your board, your funders, whoever has to sign off. It covers where your material goes, who reads it, what a report will admit it does not know, and what happens when you ask for all of it back.
Or ask us directly: book a conversation.