The Hope Standard
Technology that loves its neighbor.
A lab needs a reason to exist beyond what it can bill for. Ours is a vision borrowed from Dr. King, a plain statement of what we hold to, six values we can point to in our code, a standard we publish so anyone can hold us to it, and the bench we build on.
Our north star
Everything we build points toward a Digital Beloved Community.
Technology without humanity is just efficiency. We are building something better: technology that loves its neighbor.
Rev. Christopher Hope, Founder & Principal Consultant
Dr. Martin Luther King Jr. dreamed of a Beloved Community, a world where justice is real, poverty and exclusion are not accepted, and every person is treated as sacred. We believe that dream now has a new frontier.
Artificial intelligence is reshaping how people get hired, housed, served, and seen. It can deepen old divides or it can help close them. The difference is not the technology. It is who builds it, who it is built for, and what values guide it.
A Digital Beloved Community is a world where technology expands human dignity instead of eroding it. Where the people most often left out of the room help design the tools that shape their lives. Where no algorithm decides someone's worth. Where innovation is measured not only by what it earns, but by who it lifts.
This is our north star. Every product we release, every audit we run, and every team we train moves us one step closer to it.
When technology reflects these values, it stops being something that happens to people and becomes something that works for them. That is the Digital Beloved Community, and it is the future we are building every day.
How we build
The standard we hold ourselves to. The standard we believe everyone should meet.
We do not treat ethics as a feature. It is the foundation of every line of code we write. Every product we release is designed, tested, and audited against The Hope Standard, our framework for responsible AI, before it reaches a single user.
-
01
Privacy by design
We collect only what is needed, protect it rigorously, and never sell it.
How we check it
The check. Before we build, we write a data inventory: every field, why it exists, who can see it, and when it is deleted. If a field has no reason, it is cut.
What you will see. A plain-language data page for every product, explaining what is collected and what is not.
-
02
Algorithmic auditing
We test how our systems make decisions and document what we find.
How we check it
The check. Decisions the system makes are logged. We sample them, review them by hand, and write down what we learned, including the surprises.
What you will see. An audit summary you can actually read, not a certificate.
-
03
Bias testing
We examine our models and data for unfair outcomes before and after launch.
How we check it
The check. Outcomes are compared across groups before release and on a schedule afterward. If a gap appears, the fix ships before the feature does.
What you will see. What we tested, what we found, and what we changed.
-
04
Transparency
Users know when AI is involved and how it reaches its answers.
How we check it
The check. Anything generated or ranked by AI is labeled, shows its sources, and says how confident it is. No quiet automation.
What you will see. An "AI-assisted" label and citations right in the product.
-
05
Human judgment leads
AI assists. People decide.
How we check it
The check. No final decision about a person's money, housing, health, or job is automated. A human can always override, and a human's name is on it.
What you will see. A person's name on every recommendation that matters.
We publish how we build because we want the rest of the industry to build this way too.
Where we stand
Five things we hold to.
-
01
AI is very good computing.
It is not magic and it is not a person. Treating it as either is how organizations get hurt. Treating it as what it is, fast and tireless pattern-matching, is how they get their afternoons back.
-
02
In a community's own hands, it can serve justice.
Aimed by a community at its own welfare, a narrow AI tool can close gaps that decades of policy could not. Aimed at a community from the outside, the same technology usually extracts.
-
03
Small and specific beats big and general.
The best things we have built do one job for one organization and do it in the open: read these portals, file these purchase orders, answer these questions. Grand platforms make grand claims. Small tools keep promises.
-
04
The people who will live with a tool should have a hand in making it.
That is not a courtesy. It is how you find out what the job actually is. We co-design with communities, and we never design for them.
-
05
Technology should run at a scale a community can own.
On hardware it can afford, in formats it can leave, under rules it can read. If a tool only works while the vendor is in the room, it is not the community's tool.
An old idea, updated
Tools a community can build, fix, and decide the purpose of.
Nearly a century ago, Gandhi put up a prize for a better spinning wheel: one a village could make and repair on its own. The point was never the wheel. The point was who could make it, who could fix it, and who got to say what it was for.
We think that is the right test for AI, too. Technology in service of a community, at a scale that community can own.
Narrow tools, in a neighborhood's own hands, aimed at its own welfare. That is the tradition we are trying to extend.
Our values
The values we build by.
Our values are not posters on a wall. They are decisions we make in every line of code, every contract, and every classroom.
These are, technically, posters. Flip one over to see the decision behind it.
When technology reflects these values, it stops being something that happens to people and becomes something that works for them. That is the Digital Beloved Community, and it is the future we are building every day.
Local AI
Some of the most sensitive work should not have to leave the building.
Most of the AI industry's privacy problems come from one habit: sending everything to someone else's computer. We are pioneering the alternative inside apps like ours: local models for the steps that need them, without pretending it is our default for everything yet. Toggle the diagram to see the difference.
Figure 1
Where does your data go?
With most AI tools, every prompt is a small export of your organization's information. Copies are kept, some of it becomes training data, and the list of who else sees it is rarely written down.
In our apps, a sensitive step can run on a local model inside a boundary you can point to. We are pioneering that path and widening it as it proves out; it is not yet the default for everything, and we say so. When a task needs a frontier model, the request is stripped of what it does not need, sent under terms that prohibit training, and labeled in the interface.
Our tech stack
Open by default. Local where it fits. Boring where it counts.
A lab is only as trustworthy as the tools on its bench. Ours are chosen so that nothing we build locks an organization in, so that a person is always in the loop, and so that sensitive work can, increasingly, stay close to home.
Pioneering on-device and self-hosted models in real apps Local AI, where it fits
We are pioneering the use of local, open-weight models inside working apps like Project Lookout and Driftwood: models that run on a workstation in our lab or on a machine an organization controls, so a sensitive step can happen without the data leaving. It is not yet our default for every task, and we say so. Where the data is sensitive and the task is the right size, we offer a local path, and we keep expanding it where it holds up.
- Open-weight model families served on our own Apple silicon and Linux workstations
- Offered first for the sensitive, right-sized steps, with frontier models still doing most of the heavy lifting
- Every local path is tested against the cloud path before we offer it
Most of the heavy lifting, today Frontier models, on our terms
Most of the heavy lifting in our apps today is done by the largest commercial models: long reasoning, polished writing, unusual formats. We use them through business agreements that prohibit training on your data and limit retention, and the interface always tells you which model answered.
- Contract terms that forbid training on client data
- Data minimized before it is sent; sensitive fields stripped first
- A visible label whenever a frontier model was used
Many small workers, checked by a person Agents that verify
Project Lookout sweeps 100+ public portals and the open web every night, reads each posting into structured facts, and checks every link before a person ever sees it. Public information can be gathered anywhere. Your profile is minimized before it travels.
- Concurrent, distributed agent execution across public sources
- Structured extraction with confidence scoring and link verification
- Ranking you can inspect: every match shows why it matched
Formats you can leave Durable, exportable infrastructure
Plain files, standard databases, and open formats. If you ever want to walk away from us, you can take everything with you in a form another tool can read. We think that is the only honest way to earn a renewal.
- Standard relational databases and plain-text records
- One-click export of everything you put in
- No proprietary formats between you and your own data
Software that waits for a person Human in the loop
Every product has an approval step where a human decides. Drafts are drafts until someone signs them. Recommendations are recommendations until someone acts. The software is designed to make that step easy, not to skip it.
- Explicit approval steps on anything that affects a person
- Named owners for every automated workflow
- Overrides that are always available and always logged
Built for the people who actually use it Accessible and plain
Interfaces that meet accessibility standards, copy written at an eighth grade reading level, and training materials that assume nothing. If a tool cannot be explained simply, we do not ship it.
- Accessibility checks in every QA pass
- Plain-language documentation for every product
- Tested with the communities it is built with, not a focus group
What this means for you
Questions you get to ask us.
Because we publish how we build, you can hold us to it. Ask where your data is stored and we will point to the machine. Ask what a model was tested on and we will show you the results. Ask who decides, and a person will answer.
We wrote the questions down so you can bring them to any vendor, including us: Five questions to ask any AI vendor.