🧠 Teaching an AI Assistant What It Is Allowed to Know, Claim, and Do
I’m working on a new MyZubster milestone around Zorgax.
The interesting problem is not simply:
“How do we give an AI assistant more knowledge?”
The harder problem is:
How do we define what it is actually allowed to do with that knowledge — and how do we prove those capabilities?
That is what PR #1573 is about.
Separating contributor competence from AI capability
One of the design decisions I wanted to make explicit is that these are two different things.
A contributor record answers questions like:
- Who produced this work?
- Which repository or pull request supports it?
- What was documented, recorded or tested?
- What is the evidence state?
- What are the limitations?
A Zorgax capability answers something else:
- Which evidence may Zorgax consume?
- Which actions may it perform?
- Which claims must it not make?
- Which source state is required?
- Does the capability need a bounded test before it can be called
TESTED?
That distinction matters.
If a contributor has expertise or evidence in a domain, Zorgax should not automatically inherit that expertise as an unrestricted claim.
A machine-readable capability model
The new schema is:
myzubster.zorgax-capability.v1
A capability defines:
inputs
→ allowed actions
→ prohibited claims
→ evidence requirements
→ linked evidence
→ limitations
→ capability state
Initial states are intentionally conservative:
Contributor Profile Assistant
→ DOCUMENTED
Research Evidence Navigator
→ TESTED
Interoperability Checkpoint Assistant
→ DOCUMENTED
Only one of them starts as TESTED.
That is deliberate.
Example: contributor profiles
The Contributor Profile Assistant may use approved public evidence to:
- summarize declared professional interests;
- prepare a profile draft;
- identify provenance;
- suggest bounded onboarding steps.
But it must not:
- invent qualifications;
- infer employment;
- infer certification;
- infer Passport / LIFE / DAO participation;
- publish profile information without the required approval.
So if someone says:
“I am interested in MyZubster usability testing”
Zorgax can preserve and structure that information.
It cannot silently convert it into:
“Certified software tester.”
Example: research evidence
The Research Evidence Navigator is designed around another rule:
evidence state must survive retrieval.
If a research Knowledge Card is:
SUPPORTED
then after Zorgax retrieves or summarizes it, it is still:
SUPPORTED
not:
TESTED
not:
scientifically validated
not:
clinically certified
This capability already has a bounded contributor-scoped checkpoint behind it, which is why its current state can be TESTED.
Capability testing
The model I’m moving toward is:
Capability definition
↓
Allowed evidence
↓
Fixed / bounded procedure
↓
Observed result
↓
PASS / FAIL / PARTIAL
↓
Evidence state
Documentation alone is not enough.
A capability should become TESTED only when a reproducible bounded checkpoint supports it.
CI enforcement
I also added a validator for the Zorgax capability registry and connected it to the existing Continuous Evidence Gate.
The validator checks things such as:
- schema validity;
- duplicate capability IDs;
- registry ↔ file consistency;
- status consistency;
- whether a
TESTEDcapability actually links to boundedTESTEDcheckpoint evidence.
So capability state is not just prose anymore.
It is becoming something CI can reject.
Why this matters
A lot of AI systems are described in vague terms:
“The assistant knows X.”
I think that framing is too loose for contributor-driven systems.
I prefer:
source
→ provenance
→ evidence state
→ allowed capability
→ guardrails
→ bounded test
→ observed result
That makes it easier to answer:
- Why is Zorgax allowed to say this?
- Which source supports it?
- Is the information self-declared, supported, recorded or tested?
- What is Zorgax explicitly prohibited from inferring?
- Has this specific capability actually been tested?
Current roadmap
The broader MyZubster path is becoming:
Contributor evidence
→ machine-validatable checkpoint
→ competence / provenance registry
→ Zorgax capability registry
→ bounded capability tests
→ Passport / Knowledge Graph / workflows
without collapsing all of those states into one generic “verified” label.
PR #1573 is the first implementation of that capability layer.
Once the checks are green and the PR is merged, I’ll publish the canonical merge commit and the final capability states.
The principle behind the whole thing is simple:
AI capability should be bounded by evidence, not by confidence.
Top comments (0)