Coder Legion - Recent posts tagged yassen

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

Thu, 08 Oct 2026 16:54:32 +0000

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

Building Verified Developer Identities, Professional Profiles and Knowledge with MyZubster + Zorga

Wed, 23 Sep 2026 03:03:09 +0000

Building Verified Developer Identities, Professional Profiles and Knowledge with MyZubster + Zorgax

We are currently extending MyZubster beyond the idea of a marketplace or a metaverse.

The direction is to build an ecosystem where a user can connect:

an authenticated identity;
a verified GitHub account;
projects and repositories;
contributors;
professional skills;
practical experience;
evidence;
learning goals;
structured knowledge;
and a Metaverse identity.
That is easy to build, but it has an obvious weakness.
Anyone can write anything.
A user can claim:
Senior JavaScript Developer
Cybersecurity Expert
AI Engineer
Project Manager
without any connection to actual work, repositories, projects or evidence.
For MyZubster, we want a richer model.
The profile should be able to distinguish between:
declared skill
practical experience
verified identity
evidence
learning goal
public contribution
These are not the same thing.
GitHub as a verified identity source
GitHub is one of the first external identity sources we are integrating into the system.
When a user authenticates with GitHub, MyZubster can associate the account with a verified GitHub identity.
Conceptually:
GitHub OAuth
↓
MyZubster account
↓
verified GitHub identity
↓
repositories / README / public profile
This gives Zorgax useful context.
For example, it can inspect available public information such as:
GitHub profile
bio
public repositories
repository descriptions
languages
profile README
But we deliberately do not convert every signal into a skill automatically.
For example:
repository written in JavaScript
does not automatically become:
Advanced JavaScript Developer
Evidence is useful, but evidence and professional qualification are not identical.
Yassen: from GitHub to an authenticated Metaverse profile
We recently tested part of this flow with Yassen.
Yassen configured his GitHub profile and entered MyZubster with a complete authenticated identity.
His MyZubster identity was connected to GitHub, and he was then able to enter the Metaverse as an authenticated user.
The interesting part is that the Metaverse identity is not intended to remain just an isolated avatar.
The model becomes:
GitHub identity
```
↓
```
MyZubster account
```
↓
```
authenticated user
```
↓
```
Metaverse identity
This is important for the future architecture.
A character in the Metaverse can eventually represent a real account with real projects, contributions and evidence behind it.
Yassen also added danieldirimini-myzubster as a contributor.
That starts creating another relationship:
User
↓
Project
↓
Contributor
↓
Contribution evidence
This is the beginning of what can become a contribution graph inside MyZubster.
A contribution graph instead of isolated profiles
One of the directions we are exploring is connecting people through actual contributions.
Instead of having only:
User A
User B
User C
we can represent something more useful:
User A
│
├── Project X
│ ├── Repository
│ ├── Contribution
│ └── Evidence
│
└── Collaborated with User B
This can later connect to:
GitHub commits
pull requests
project activity
knowledge contributions
reviews
verified evidence
The goal is not simply to measure popularity.
It is to understand:
What has this person actually contributed?

Fixing an AI onboarding problem
While developing the professional profile onboarding flow, we found an interesting issue.
Zorgax was supposed to interview the user.
For example:
What practical activities can you do?
But an AI assistant can sometimes interpret that as:
What can YOU, the assistant, do?
That is obviously wrong for a professional-profile questionnaire.
So we changed the onboarding prompt.
Zorgax is now explicitly instructed to:
interview the user
ask about the user's experience
never answer the questionnaire as Zorgax
never attribute Zorgax capabilities to the user
ask one question at a time
wait for the user's response
The principle behind this fix is simple:
AI should help structure the user's identity, not generate an identity for the user.

Structured professional profiles
We also introduced a structured professional-profile model.
Instead of storing only a free-text biography, MyZubster can represent data such as:
headline
summary
skills
experiences
interests
professional goals
collaboration availability
evidence
visibility
approval status
version
timestamps
A simplified skill object can look like this:
{
"name": "Kali Linux / Cybersecurity",
"category": "technology",
"experience": "10+ years of self-directed study and practice",
"level": "Self-taught practical experience",
"evidence": [],
"notes": "Only legitimate and authorized security activity is represented"
}
This format is more useful than a simple string such as:
Cybersecurity
because it preserves context.
Explicit approval before persistence
Another important part of the implementation is approval.
The backend does not accept a professional profile as approved by default.
A write request needs explicit approval:
{
"approved": true,
"visibility": "private",
"profile": {}
}
or:
{
"approved": true,
"visibility": "public",
"profile": {}
}
The onboarding UI exposes two separate actions:
Approve and save privately
and:
Approve and publish on MyZubster
This means the AI cannot silently publish the profile.
The user makes the final decision.
Private and public are different states
This distinction is important for both profiles and knowledge.
A useful mental model is:
conversation

↓

draft

↓

user review

↓

approval
/ \
/ \
private public
Not everything discussed with Zorgax belongs in the public profile.
Not every personal experience should become public data.
Not every profile claim should become public knowledge.
Building my own professional profile
We are now using the same infrastructure to structure my own professional profile.
The goal is not to make an exaggerated CV.
The goal is to represent real experience accurately.
My profile currently includes areas such as:
MyZubster project management
GitHub
Linear
Vercel
ChatGPT / Zorgax
terminal / VPS
Kali Linux
cybersecurity
calisthenics
Thai boxing
MMA
event organization
visual systems
audio systems
barista work
kefir
gardening
botany
permaculture
volunteering
self-directed psychology study
But each area is described with its actual context.
For example:
GitHub / Linear / Vercel
is represented as operational usage.
It is not automatically converted into:
Senior Software Engineer
MyZubster as a learning environment
A major part of my own professional goal is to make MyZubster my main work.
At the same time, I am using the project itself to develop new skills.
That means the profile can represent both:
things I already know
and:
things I am learning
For example, I want to continue improving in:
software development
AI
cybersecurity
project management
product development
video mapping
This allows the profile to represent a progression rather than pretending every skill is already complete.
Evidence-aware profiles
Another important part is evidence.
A claim can eventually be associated with evidence such as:
GitHub repositories
project activity
videos
photos
public contributions
documents
other verified sources
This does not mean the system blindly trusts every piece of evidence.
It means evidence can be attached to a claim and reviewed separately.
Conceptually:
Skill
↓
Experience
↓
Evidence
↓
Verification
From professional profiles to knowledge
The same architecture can be extended to knowledge.
This is where things become more interesting.
For example, I have several years of practical experience preparing kefir.
That can be represented as:
personal experience
But it should not immediately become:
verified universal knowledge
Those are different concepts.
So MyZubster Knowledge follows another principle:
message != knowledge
candidate != verified
verified != public
A user can contribute a knowledge candidate.
Then that candidate can be connected to:
sources
evidence
contributors
review
verification
Only after that process should it become part of a public knowledge layer.
The Knowledge Explorer
We have also been building a public Knowledge Explorer.
Its role is to expose only knowledge that has reached an appropriate state.
The public frontend is intended to avoid displaying:
internal candidates
pending review content
unverified material
Instead, public search should operate on verified or approved knowledge.
Conceptually:
candidate
↓
review
↓
approved
↓
public search
Zorgax is the orchestration layer
It is important to clarify what Zorgax is.
Zorgax is not simply a language model that we trained from scratch.
It is the AI and orchestration layer of MyZubster.
It can work with:
LLM providers
MyZubster user profiles
GitHub
verified knowledge
evidence
workflow rules
human approval
project context
Metaverse identities
The architecture looks roughly like this:

                MyZubster
                    |
    +---------------+---------------+
    |                               |
  Profiles                       Knowledge
    |                               |
  GitHub                          Evidence
    |                               |
 Projects                        Sources
    |                               |

Contributions Verification

    \                               /
     \                             /
      +----------- Zorgax --------+
                    |
                Metaverse

Zorgax helps move information between these systems, but it should not bypass verification or user approval.
Why the Metaverse matters
This also changes the role of the Metaverse.
A traditional Metaverse avatar might only have:
name
appearance
position
A MyZubster identity can eventually have:
authenticated account
verified GitHub
professional profile
projects
contributors
skills
evidence
knowledge contributions
So a Metaverse character can become a visual interface for a much richer identity graph.
For example:
Yassen
│
├── authenticated MyZubster account
├── verified GitHub profile
├── Metaverse identity
├── project relationships
└── contributors
And the same model can eventually apply to every user.
What we have implemented so far
At this stage, we already have several important pieces working:
GitHub identity integration
authenticated MyZubster accounts
Metaverse authentication
structured professional profiles
private/public visibility
explicit profile approval
evidence-aware fields
Zorgax profile onboarding
profile questionnaire safeguards
public Knowledge Explorer
knowledge verification states
contributor relationships
Vercel deployment infrastructure
We also added automated tests around the professional-profile flow.
The tests cover areas such as:
profile normalization
approval requirements
private/public visibility
professional profile import
onboarding JavaScript validity
questionnaire perspective
Current deployment work
We recently connected the structured professional-profile backend to the onboarding interface.
The flow now supports:
load professional profile
↓
preview structured data
↓
explicit approval
↓
save private OR publish
The relevant implementation was merged into the canonical development branch.
We also verified automated tests before deployment.
At the infrastructure level, we are currently deploying the updated MyZubster gateway and knowledge services through Vercel.
The gateway deployment has already been successfully built and marked ready for production.
The Knowledge deployment is the next part of the rollout.
The bigger architecture
The long-term direction is to connect these systems into one graph.
Identity
↓
Profile
↓
Experience
↓
Evidence
↓
Contribution
↓
Verification
↓
Knowledge
↓
Collaboration
GitHub provides one strong source of identity and technical evidence.
The Metaverse provides a spatial and social interface.
Zorgax provides AI-assisted orchestration.
MyZubster Knowledge provides structured, reviewable knowledge.
The professional profile connects the person to all of these layers.
What we are trying to avoid
There are several things we explicitly do not want:
AI-generated fake skills
unverified professional claims
automatic public publishing
anonymous claims treated as verified facts
repository languages treated as expertise
private experiences becoming public automatically
Instead, the system should preserve distinctions.
For example:
self-taught != certified
practical experience != professional qualification
evidence != verification
candidate knowledge != verified knowledge
private != public
Those distinctions make the system more complex, but also much more useful.
What comes next
The next work is mainly about connecting the graph more deeply.
We want profiles to connect to:
GitHub repositories
contributors
projects
knowledge contributions
evidence
Metaverse identities
and we want Zorgax to help navigate these relationships.
My own professional profile is currently one of the real-world cases we are using to test this architecture.
The objective is not just to build another résumé.
The objective is to build a system that can represent:
what a person knows
what they have done
what they are learning
what evidence exists
who they collaborated with
what knowledge they contributed
while keeping the user in control of what becomes public.
That is the direction we are taking MyZubster.
Final thought
For me, the most interesting part of this project is not any single feature.
It is the connection between them.
GitHub alone is useful.
A professional profile alone is useful.
A Metaverse alone can be interesting.
An AI assistant alone is useful.
A knowledge base alone is useful.
But when these pieces are connected through identity, evidence, contributions and verification, they become something different.
That is what we are experimenting with through MyZubster and Zorgax.

erience, evidence, AI-assisted onboarding and Metaverse identities into one verifiable ecosystem.**

Zorgax acts as the AI layer that helps connect these parts, but with an important rule:

AI can help structure information, but it should not invent a user's identity or publish claims without explicit approval.

This article explains what we have already implemented, what happened with one of our early users, Yassen, and what we are now doing with my own professional profile and knowledge inside MyZubster.

The core problem

A normal user profile is usually just a collection of manually entered fields:

name
bio
skills
links

Coder Legion - Recent posts tagged yassen

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

Separating contributor competence from AI capability

A machine-readable capability model

Example: contributor profiles

Example: research evidence

Capability testing

CI enforcement

Why this matters

Current roadmap

The core separation

Capability schema

Example: contributor profiles

Example: research evidence

Machine-validatable capability states

Why this matters

Broader direction

Building Verified Developer Identities, Professional Profiles and Knowledge with MyZubster + Zorga

Building Verified Developer Identities, Professional Profiles and Knowledge with MyZubster + Zorgax

The core problem

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