Approach · Knowledge architecture
Every fact needs a source, a date and someone who can confirm it.
We decide what an organization knows, where that knowledge lives, who can confirm it, and how to structure it so people, software and AI agents can rely on it. This is where Business Truth starts.
How we approach it
- 01
Separate what was said from what is confirmed.
A meeting note, a listing or an AI answer is an observation. A fact enters the record when someone with authority confirms it, and it keeps that person's name and the date.
- 02
Give every fact a state.
Confirmed, needs review, unknown, or stopped, which means it must not be published. Facts age, so a stale one gets checked again.
- 03
Never let an observation overwrite the record.
When a website, a listing or an AI answer disagrees with a confirmed fact, it opens a conflict for a person to resolve.
- 04
Set permissions as part of the structure.
Approved facts about what the business offers can be published. Customer records, financials, contracts and internal policies stay behind the controls they already have.
- 05
Structure it for the systems that will read it.
Pages and plain-text files state the same facts a person reads, in a form search engines and AI can read too.
Questions it answers
- What does the organization actually know, and where is it written down?
- Who has the authority to confirm or change each fact?
- What should happen when two sources disagree?
In practice
Where this shows up in our own work, with each item's current status.
- D.W. Ross: Business Truth discovery and information architecture before any page was designedUsed internally
- D.W. Ross: a website built from one registry of facts, live since September 17, 2026In production
- An observation opens a conflict for a person instead of overwriting a confirmed factUsed internally
Tell us what you're trying to accomplish.
We'll talk through the problem, whether Lehvel is a good fit, and a sensible next step. The scope comes from the problem, not a package.