WHERE IT APPLIES
The same foundation, in very different contexts.
Accountability is not a sector-specific problem. OZLILI does not build a different product for each industry. What changes between domains is the vocabulary, the rules, and what counts as proof — and those are configuration on one foundation, not a second codebase.
THE FOUNDATION
One mechanism. The domain is configuration.
Before the domains, the principle. The architecture underneath every OZLILI product does not change when the industry does. Three things move — and only three.
The foundation is the same. The domain is what you configure on top of it.
Vocabulary
Each domain has its own words for capability, evidence and readiness. The system carries them as configuration, not as a separate codebase. A credential in healthcare and a certification in energy are the same kind of record with a different name.
Rules
What a domain accepts as proof — a license, a peer review, a regulator's sign-off — is a rule applied to evidence, not a product feature built from scratch. The rule changes; the engine that applies it does not.
Proof
What counts as proof varies. The mechanism for checking it does not. The Evidence Engine is the same in every domain; what it checks against is what the domain provides.
WHERE THE PROBLEM IS SHARPEST
Six domains where the architecture is most relevant.
These are the domains where the problem OZLILI solves is most acute. They are not a customer list and not a market map — they are where the foundation's properties meet a real, named need. Each one is the same mechanism applied to a different shape of accountability.
Healthcare
Competence is licensed, revalidated and audited. What counts as proof is written down by somebody else — and has to be produced on request.
The evidence layer maps directly: credentials, continuing development, and competency reviews are all claims that need to be traceable to their source.
Government
Decisions about people are made in public and questioned in public. The reasoning has to survive being read years after it was recorded.
The Trust Architecture — decisions stored with their reasoning at the time — is the mechanism this domain has been asking for.
Education
A qualification says someone completed something. It rarely says what they can now do. The distance between those two is the whole problem.
Evidence and assessment design close that distance: what was learned, what was demonstrated, and what the learner can now actually do.
Finance
Regulated roles, documented approvals, and reviews that reopen a decision long after the people who made it have moved on.
The audit-by-default property — a decision recorded with its reasoning, not reconstructed for the review — is what this domain's review cycles need.
Energy and industry
Certifications expire and sites are unforgiving. "Qualified" has to mean qualified today, not qualified at some point in the past.
Retention by design and evidence aging — how a record that was correct when made stays correct over time — are the problems this domain lives with.
HR and talent
The domain OZLILI was built in. Hiring, development and performance run on impressions unless something is keeping the evidence.
This is the foundation's home ground. Company ships here today; the other domains are configuration on the same architecture.
Not a customer list.
The domains above are where the problem is sharpest. OZLILI does not claim a deployment in any of them yet. If you work in one and the problem is yours, we would like to talk.