Question

🧠 Teaching an AI Assistant What It Is Allowed to Know, Claim, and Do

We just merged a new MyZubster milestone around Zorgax.

PR #1573 introduced an evidence-bound capability model for the assistant.

The question behind it was 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 capability layer is now merged.

Canonical merge:

4974cd5188603704a118ae41b35e14fa5c43f03f

All four repository gates passed before merge:

• CI – Test e Lint
• Continuous Evidence Gate
• MYZ-164 Seller Free policy
• Security Audit

Separating contributor competence from AI capability

One of the key design decisions is that these are two different things.

A contributor record answers:

• 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:

• 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.

Contributor evidence does not automatically become unrestricted AI expertise.

A machine-readable capability model

The new schema is:

myzubster.zorgax-capability.v1

Conceptually:

inputs
→ allowed actions
→ prohibited claims
→ evidence requirements
→ linked evidence
→ limitations
→ capability state

Initial canonical capability states:

Contributor Profile Assistant
→ DOCUMENTED

Research Evidence Navigator
→ TESTED

Interoperability Checkpoint Assistant
→ DOCUMENTED

Only one 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 evidence state and provenance;
• suggest bounded onboarding steps.

But it must not:

• invent qualifications;
• infer employment;
• infer certification;
• infer Passport / LIFE / DAO participation without separate consent;
• publish profile information without the required approval.

A self-declared interest stays self-declared.

It does not silently become verified competence.

Example: research evidence

The Research Evidence Navigator follows another important rule:

evidence state survives retrieval.

If a research source is:

SUPPORTED

then after Zorgax retrieves or summarizes it, it remains:

SUPPORTED

not:

TESTED

not:

scientifically validated

not:

clinically certified

This capability already has bounded contributor-scoped checkpoint evidence behind it, which is why it can currently be marked TESTED.

Capability testing

The model is now:

Capability definition
        ↓
Allowed evidence
        ↓
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

The capability registry is machine-validated.

The Continuous Evidence Gate now checks:

• schema validity;
• duplicate capability IDs;
• registry ↔ file consistency;
• status consistency;
• whether a TESTED capability actually links to bounded TESTED checkpoint evidence.

So capability state is no longer just prose.

It is something CI can reject.

Why this matters

A lot of AI systems are described in vague terms:

“The assistant knows X.”

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.

The principle behind the whole milestone is simple:

AI capability should be bounded by evidence, not by confidence.

Next step: move the Contributor Profile Assistant from DOCUMENTED to TESTED through a real bounded contributor checkpoint.

We just merged a new MyZubster capability layer for Zorgax.

PR #1573 introduced a machine-readable model for defining what an AI assistant is allowed to know, claim, and do.

Canonical merge:

4974cd5188603704a118ae41b35e14fa5c43f03f

Before merge, all repository gates passed:

CI – Test e Lint
→ PASS

Continuous Evidence Gate
→ PASS

MYZ-164 Seller Free policy
→ PASS

Security Audit
→ PASS

The core separation

I’m separating two concepts that are often mixed together:

Contributor competence / evidence

and

AI capability

A contributor record describes:

• repository / PR / commit provenance;
• documented or tested work;
• evidence state;
• explicit limitations;
• consent boundaries.

A Zorgax capability describes:

• allowed input sources;
• allowed actions;
• prohibited claims;
• minimum evidence requirements;
• linked checkpoints;
• limitations;
• capability state.

Contributor expertise does not automatically become unrestricted AI expertise.

Capability schema

The first version uses:

myzubster.zorgax-capability.v1

A capability looks conceptually like:

source evidence
    ↓
allowed inputs
    ↓
allowed actions
    ↓
must-not rules
    ↓
evidence requirements
    ↓
linked checkpoints
    ↓
capability state

Initial canonical capabilities:

zorgax.contributor-profile-assistant
→ DOCUMENTED

zorgax.research-evidence-navigator
→ TESTED

zorgax.interoperability-checkpoint-assistant
→ DOCUMENTED

The asymmetry is intentional.

Documentation does not equal testing.

Example: contributor profiles

The Profile Assistant may:

• summarize declared interests;
• prepare profile drafts;
• preserve provenance;
• suggest bounded onboarding steps.

But it must not:

• invent qualifications;
• infer certification;
• infer employment;
• infer Passport / LIFE / DAO participation;
• publish contributor information without the required approval.

So a self-declared interest stays self-declared.

It does not silently become verified competence.

Example: research evidence

The Research Evidence Navigator has a stricter evidence-preservation rule.

If a source is:

SUPPORTED

then Zorgax retrieval must preserve:

SUPPORTED

It must not turn it into:

TESTED

or “scientifically validated”

or “clinically certified”.

This is one of the places where evidence semantics matter more than fluent output.

Machine-validatable capability states

The repository now validates capability definitions in CI.

The validator checks:

• JSON Schema validity;
• duplicate capability IDs;
• registry/file consistency;
• capability status consistency;
• whether a TESTED capability actually links to TESTED bounded checkpoint evidence.

The intended lifecycle becomes:

PROPOSED
→ DOCUMENTED
→ IN_VERIFICATION
→ TESTED

with:

DISABLED

available when a capability should no longer be used operationally.

Why this matters

A common AI architecture pattern is:

model + tools + instructions

But that still leaves a governance problem:

Which tool-assisted claims are actually supported?

The model we are moving toward is:

evidence
→ provenance
→ capability
→ guardrails
→ bounded test
→ observed result
→ state

This gives us a way to ask:

• Which source supports this?
• Is it documented, supported, recorded or tested?
• Is the assistant allowed to act on it?
• Has that specific capability passed a bounded checkpoint?
• What is explicitly outside scope?

Broader direction

This now connects directly with the contributor evidence model already implemented in MyZubster:

Contributor work
→ machine-validatable interoperability checkpoint
→ provenance / competence records
→ Zorgax capability registry
→ bounded capability tests
→ optional Passport / Knowledge Graph workflows

without collapsing technical evidence, contributor identity, consent, publication, certification, payment and governance into one generic “verified” state.

The design principle is:

AI capability should be evidence-bound, not confidence-bound.

The capability registry is now merged and enforced by CI.

The next step is no longer schema design.

It is execution:

take zorgax.contributor-profile-assistant from DOCUMENTED to TESTED through a real bounded contributor checkpoint.