Building a Verified Knowledge Layer for Zorgax — and Turning It Into a Developer Marketplace

Building a Verified Knowledge Layer for Zorgax — and Turning It Into a Developer Marketplace
How we moved Zorgax from a conversational assistant toward a persistent, reviewable knowledge system — and what comes next for MyZubster Development.
During the last development cycle of MyZubster, we reached an important architectural question:
What happens when an AI assistant stops being only a chat interface and starts accumulating knowledge about the system it helps build?

For Zorgax, our answer is not “let the model remember everything.”
It is almost the opposite.
We are building a verified knowledge layer where information has provenance, review status, visibility rules, evidence, and an explicit path from discovery to publication.
This is the first step toward something larger: Zorgax Development, a marketplace where verified knowledge can become specifications, development requests, bounties, implementations, reusable modules, and new knowledge.
The Problem: Chat Is Not Knowledge
An AI conversation can contain useful information, but that does not make every statement true.
The same applies to:

• web search results,
• repository observations,
• user messages,
• model-generated explanations,
• old documentation,
• test output,
• roadmap ideas. We therefore started with one fundamental rule: message != knowledge candidate != verified verified != public This distinction is becoming one of the most important architectural boundaries inside Zorgax. Instead of allowing the assistant to silently “learn” whatever appears in a conversation, knowledge goes through an explicit lifecycle. We Already Had More Infrastructure Than We Expected Before creating another database or another model, we audited the existing MyZubster architecture. We found that the project already contained several useful building blocks: KnowledgeContribution Knowledge reward flows Knowledge evidence Evidence hashing ResearchDocument ZorgaxMemory MYZ reward lifecycle Independent review That changed the implementation strategy. Rather than creating a completely separate KnowledgeAsset system, we extended the existing knowledge infrastructure and made Zorgax a consumer and producer of that system. This matters because duplicated truth systems eventually disagree. We want one canonical knowledge lifecycle. The New Zorgax Knowledge Flow The first implemented vertical slice now looks like this: User / Engineering Work ↓ Zorgax Knowledge Preview ↓ Deterministic SHA-256 Digest ↓ Explicit Human Confirmation ↓ PENDING_REVIEW ↓ Independent Review ↓ APPROVED ↓ Internal Zorgax Retrieval ↓ Explicit Publication ↓ PUBLIC Knowledge There are several deliberate safety boundaries inside this flow.
• Zorgax Does Not Persist Knowledge Automatically When knowledge is prepared, Zorgax first creates a preview. Conceptually: { title: "Kefir community contract", category: "marketplace", description: "Kefir culture listings are FREE-only." } A deterministic SHA-256 digest is generated from the normalized preview. The user then receives an explicit confirmation token such as: CONFERMA a1b2c3d4 Nothing persistent has happened yet. Only after the exact preview is confirmed can it enter the knowledge database. If the preview changes after confirmation, the digest changes and the write is rejected. This gives us a useful invariant: Human confirmation applies to the exact data being persisted, not merely to the general intention to save something.

1. New Knowledge Starts as INTERNAL A confirmed knowledge contribution does not immediately become public documentation. It starts as: status = PENDING_REVIEW visibility = INTERNAL That gives us two independent dimensions: verification state visibility state They are intentionally separate. For example: PENDING_REVIEW + INTERNAL APPROVED + INTERNAL APPROVED + PUBLIC REWARDED + PUBLIC A contribution can therefore be verified without automatically becoming public.

2. Legacy Knowledge Fails Closed
   One subtle problem appears when adding visibility rules to an existing database.
   What should happen to older records that do not yet contain a visibility field?
   We chose the conservative behavior:
   missing visibility = INTERNAL
   Not PUBLIC.
   That means deploying the new feature cannot accidentally expose historical knowledge.
   This is a small implementation detail, but it represents a larger rule we use throughout MyZubster:
   When authorization or privacy metadata is missing, fail closed.

3. Public and Internal Retrieval Are Different
   Zorgax now distinguishes two knowledge scopes.
   For normal or guest requests:
   PUBLIC knowledge only
   For explicitly authorized internal/admin contexts:
   PUBLIC + INTERNAL verified knowledge
   The assistant never receives PENDING_REVIEW or REJECTED contributions as canonical context.
   The verified states currently accepted by retrieval are:
   APPROVED
   REWARD_ELIGIBLE
   REWARDED
   That gives us a much stronger model than “search every document and put it into the prompt.”

4. Verified Knowledge Is Injected Into the Zorgax Prompt
   Once retrieval was working, we connected it to the shared Zorgax assistant prompt.
   The runtime context can now contain a section conceptually similar to:
   INTERNAL VERIFIED KNOWLEDGE

[K1] Public marketplace invariant
status=APPROVED
visibility=PUBLIC
category=marketplace

Kefir culture listings are FREE-only.
Internal items are injected only when the request has the appropriate scope.
This means Zorgax can now answer using three different classes of context:
Canonical runtime facts
Verified internal/public knowledge
Live external research
Those sources are not treated as equivalent.
That distinction will become increasingly important as the system grows.
Knowledge Is Not the Same as Memory
MyZubster already has ZorgaxMemory, but we intentionally did not turn it into the canonical knowledge database.
They serve different purposes.
Zorgax Memory
Useful for temporary/user-related conversational context.
It already distinguishes claims such as:
verified
uncertain
speculative
fictional
and can expire through TTL.
ResearchDocument
Stores retrieved/crawled material.
It includes fields such as content hashes and crawl timestamps.
But retrieved material is still evidence — not automatically truth.
KnowledgeContribution
This is where reviewed shared knowledge lives.
That separation gives us:
Memory
≠
Research
≠
Verified Knowledge
We Kept Knowledge Rewards Separate From Knowledge Truth
MyZubster already has a knowledge-to-MYZ contribution flow.
We preserved an important invariant:
Creating knowledge does not automatically create a reward.

The lifecycle can move through states including:
PENDING_REVIEW
APPROVED
REJECTED
REWARD_ELIGIBLE
REWARDED
Independent review is required.
Reward eligibility is another step.
And final reward state requires authoritative ledger evidence.
The knowledge system therefore does not say:
AI generated something
→ pay someone
Instead:
Contribution
→ Review
→ Verification
→ Eligibility
→ Ledger process
This will matter a lot once we connect knowledge to development work.
We Also Fixed Zorgax Live Research
While integrating the knowledge layer, one regression test exposed another useful architectural inconsistency.
The Zorgax capability endpoint said that Google News was available, and the tests expected current/time-sensitive queries to use it before Wikipedia.
But the implementation still contained:
async function googleNewsSearch() {
return [];
}
The capability existed conceptually, but not operationally.
We implemented a lightweight Google News RSS fallback without introducing another parsing dependency.
For time-sensitive queries, the search strategy now becomes conceptually:
Brave Search
Tavily
Google News
Wikipedia
When paid search API keys are absent:
Google News
Wikipedia
For non-current informational queries, Wikipedia remains a useful background fallback.
This distinction matters because these questions are fundamentally different:
"What is climate?"
and:
"What are the latest climate developments today?"
Freshness is part of the query semantics.
The targeted Zorgax assistant and Knowledge regression tests are now green. Full-suite verification remains a release gate before considering that stabilization cycle complete.
Testing the Knowledge Boundary
We added tests specifically for the new invariants.
Among other things, the tests verify that:
A preview does not persist data.

Changing a preview invalidates its digest.

Confirmed knowledge enters as PENDING_REVIEW.

New contributions default to INTERNAL.

Public retrieval returns only explicitly PUBLIC knowledge.

Internal retrieval can include verified INTERNAL knowledge.

Unreviewed knowledge never reaches the assistant prompt.

Guest prompts cannot receive INTERNAL knowledge.

Admin/internal prompts can receive INTERNAL knowledge.

Knowledge retrieval fails safely when MongoDB is unavailable.
The current focused regression set for this vertical slice passes:
5 test suites
25 tests
25 passing
We also integrated the work using an isolated Git worktree so an unrelated Zorgax research fix and another untracked verifier project were not accidentally mixed into the Knowledge commit.
That operational discipline matters too.
A reliable architecture can still be damaged by careless integration.
The Larger Goal: Zorgax Development
The Knowledge DB is not the final product.
It is infrastructure for the next layer.
We want knowledge to become executable development coordination.
The future loop looks like this:
Engineering Work
↓
Evidence
↓
Candidate Knowledge
↓
Verification
↓
Knowledge DB
↓
Specification
↓
Development Request
↓
Proposal
↓
Bounty
↓
Implementation
↓
Tests
↓
Verification
↓
Accepted Delivery
↓
Reward
↓
Reusable Module
↓
New Knowledge
This is the foundation of what we call Zorgax Development.
Knowledge Should Be Open. Execution Has Value.
We do not want to put a paywall around every technical fact.
The more interesting economic model is:
Knowledge is open. Execution has value.

A verified architecture decision can be public.
A privacy invariant can be public.
A testing pattern can be public.
But someone may still need help turning that knowledge into:

• an implementation,
• an integration,
• a migration,
• an audit,
• a reusable module,
• an automation,
• a deployment,
• a security review,
• a verified delivery. That is where a development marketplace becomes useful. A Future Development Request Could Look Like This Instead of publishing only free-form job descriptions, Zorgax could generate machine-readable development requests from verified knowledge. For example: { "title": "Add verified Knowledge retrieval to an assistant", "domain": "ai-infrastructure", "requirements": [ "Only reviewed knowledge can enter canonical context", "Internal knowledge must never reach guest users", "Persistent writes require explicit confirmation", "Legacy records must fail closed" ], "acceptanceTests": [ "guest receives PUBLIC knowledge only", "admin may receive INTERNAL knowledge", "PENDING_REVIEW records are excluded" ], "evidenceRequired": [ "passing tests", "commit reference", "review record" ] } That request could then become: DevelopmentRequest → Proposal → Bounty → Delivery → Verification The knowledge itself becomes part of the specification. Evidence-Based Reputation Instead of Stars A development marketplace also needs reputation. We do not want reputation to be only: ★★★★★ Instead, reputation can be derived from actual evidence:
• accepted pull requests,
• verified deliveries,
• passing contract tests,
• maintained modules,
• successful security reviews,
• useful knowledge contributions,
• independent reviews,
• resolved disputes,
• reverted or failed deliveries. The goal is not to create a popularity score. The goal is to answer: What has this contributor demonstrably delivered?

Selective Decentralization
We are also interested in decentralized verification, but that does not mean putting the entire Knowledge DB on-chain.
That would be expensive, inflexible, and unnecessary.
A more useful split is:
Off-chain
documentation
source code
knowledge content
search indexes
embeddings
development artifacts
Verifiable / potentially on-chain
content hashes
authorship references
licenses
bounty references
acceptance commitments
settlement references
evidence anchors
The chain can help verify commitments.
It does not need to become the document database.
Search and Embeddings Will Be Derived, Not Canonical
The current MVP can work with MongoDB and structured filtering.
Later we can add:
full-text search
semantic search
embeddings
vector indexes
graph relationships
But those will be derived indexes.
The canonical object remains the reviewed Knowledge record.
This prevents a vector database from silently becoming the definition of truth.
Automatically Generated Knowledge — Without Automatically Generated Truth
Eventually, Zorgax should be able to observe engineering evidence such as:
commits
test results
pull requests
architecture decisions
runtime contracts
evidence hashes
documentation changes
and propose new Knowledge candidates automatically.
For example:
Commit:
fix(kefir): enforce free-only culture donations

Tests:
kefirMarketplaceContract
kefirHandDelivery

Extracted candidate:
"Kefir culture listings in the community marketplace are FREE-only."
But the important word is candidate.
Automation can accelerate extraction.
It should not silently promote its own conclusions to verified truth.
So the future system remains:
automatic extraction
↓
candidate
↓
evidence
↓
verification policy / human review
↓
canonical knowledge
What Comes Next
The immediate roadmap is now clearer.
We want to extend Knowledge records with stronger provenance and versioning, connect engineering evidence automatically, improve internal search, expose selected verified assets through the public MyZubster Knowledge site, and then introduce the first DevelopmentRequest lifecycle.
From there, Zorgax can begin transforming questions into structured work.
A user could eventually ask:
“Can MyZubster support verified repair services in the Marketplace?”

Instead of producing only an answer, Zorgax could reason through the existing Knowledge DB and generate:
Known architecture
Missing capability
Required invariants
DevelopmentRequest
Acceptance tests
Evidence requirements
Potential bounty
That is where the assistant becomes more than a chatbot.
It becomes part of the development coordination layer.
The Direction
The architecture we are building can be summarized with one loop:
QUESTION
↓
KNOWLEDGE
↓
ARCHITECTURE
↓
DEVELOPMENT REQUEST
↓
IMPLEMENTATION
↓
TESTS
↓
VERIFICATION
↓
DELIVERY
↓
REWARD
↓
NEW KNOWLEDGE
Zorgax is starting to sit in the middle of that loop.
Not as an autonomous authority.
Not as a model that “knows everything.”
But as an evidence-aware system capable of turning verified knowledge into useful action while keeping human confirmation, review, privacy, and verification boundaries explicit.
That is the foundation we want for Zorgax Development.
We did not come to automate trust. We came to make trust verifiable.