DEV Community

Daniel Ioni
Daniel Ioni

Posted on

Rebuilding the MyZubster Knowledge Explorer as a Static, Evidence-Aware Knowledge Interface

#myzubster #knowledge #interface #explorer

Rebuilding the MyZubster Knowledge Explorer as a Static, Evidence-Aware Knowledge Interface

The MyZubster Knowledge Explorer already exposed a catalogue of canonical records across domains such as Fermentation, Monero, Programming, Art, Sport, Martial Arts and Animals.

The problem was not data availability. The problem was interaction architecture.

The previous page mixed domain discovery, record search, evidence interpretation and record inspection in one long visual flow. It was possible to browse the catalogue, but difficult to answer basic operational questions:

  • Which records belong to a domain?
  • Is this item a personal practice, an observation, a protocol or an external source?
  • Can I search by stable record ID?
  • How do I distinguish a documented claim from independently verified guidance?

We rebuilt public/knowledge.html as a static, client-side knowledge explorer with explicit evidence boundaries.

The updated page is deployed at:

https://myzubster-knowledge-myzubster.vercel.app/knowledge.html

Deployment surface

The implementation intentionally uses the smallest possible deployment surface:

myzubster-knowledge/
└── public/
    └── knowledge.html
Enter fullscreen mode Exit fullscreen mode

There is no new backend service, database migration, serverless function or framework runtime.

The page is a self-contained HTML document containing:

  • semantic HTML;
  • CSS design tokens and responsive layout rules;
  • a client-side record registry;
  • domain navigation;
  • full-text filtering;
  • evidence-state filtering;
  • an inline record-detail renderer.

The Vercel deployment path remains static:

cd /root/myzubster-knowledge

cp public/knowledge.html \
  "public/knowledge.html.bak.$(date +%F-%H%M%S)"

install -m 0644 /tmp/knowledge.html public/knowledge.html

vercel --prod --yes --scope myzubster
Enter fullscreen mode Exit fullscreen mode

A timestamped backup is created before replacement. The deployment can therefore be rolled back without relying on an untracked local copy.

The record model

The initial implementation uses an in-memory JavaScript registry:

{
  id: "MZ-001",
  title: "Knowledge Layer — canonical record protocol",
  domain: "MyZubster",
  state: "PROTOCOL",
  description:
    "Defines the Knowledge Explorer as a catalogue of traceable records with a stable ID, domain, evidence state, provenance and review boundary."
}
Enter fullscreen mode Exit fullscreen mode

The model is intentionally minimal, but it establishes the fields required for a future canonical-record format:

Field Purpose
id Stable, human-readable identifier
title Record title
domain Knowledge domain
state Evidence classification
description Human-readable context and limitations

The next iteration should externalize these records into versioned Markdown files with validated front matter:

id: AHP-002
title: Absorbent-product experience contribution model
domain: CIRCULAR_ECONOMIES
evidence_state: PROTOCOL
review_status: PROPOSED
provenance: UNKNOWN
source_version: 1
Enter fullscreen mode Exit fullscreen mode

That would make the website a generated view over source-controlled knowledge objects rather than a manually maintained client-side array.

Evidence states are a first-class UI concern

The explorer does not present every entry as equally reliable.

Current values include:

PERSONAL_PRACTICE
OBSERVATION
EXTERNAL_SOURCE
PROTOCOL
Enter fullscreen mode Exit fullscreen mode

These are not cosmetic labels. They encode the epistemic boundary of a record:

  • PERSONAL_PRACTICE: first-hand practice reported by a contributor;
  • OBSERVATION: a documented observation that may still require reproduction;
  • EXTERNAL_SOURCE: a claim linked to an identifiable external source;
  • PROTOCOL: a proposed method, data model or verification procedure.

The core product rule is:

A stored record is not automatically verified guidance.

This is especially important for health-adjacent, environmental and circular-economy content. Data integrity, document provenance and scientific validity are separate properties.

Search implementation

The page supports a composable filter pipeline based on:

  1. selected domain;
  2. selected evidence state;
  3. free-text query.

The current filtering implementation is deliberately framework-free:

const list = records.filter((record) =>
  (active === "All" || record.domain === active) &&
  (!state || record.state === state) &&
  `${record.id} ${record.title} ${record.domain} ${record.description}`
    .toLowerCase()
    .includes(query)
);
Enter fullscreen mode Exit fullscreen mode

This approach is sufficient for a small static catalogue and has predictable runtime behaviour:

  • no server round trip;
  • no dependency on a search provider;
  • no indexing infrastructure;
  • deterministic results;
  • zero persistence requirements.

For larger catalogues, the next step should be build-time index generation and client-side indexed search rather than a backend search API by default.

Domain navigation

The domain list is derived from a fixed domain registry and rendered dynamically:

const allDomains = [
  "All",
  "MyZubster",
  "Circular economies",
  "Fermentation",
  "Monero",
  "Sound system",
  "Music",
  "Art",
  "Sport",
  "Martial arts",
  "Programming",
  "University",
  "Animals",
  "Permaculture",
  "Collaboration"
];
Enter fullscreen mode Exit fullscreen mode

Each domain displays its active record count. Empty domains remain visible rather than being removed.

That is intentional. An empty domain is not necessarily a missing feature. It can represent a mapped knowledge area that is ready to receive documented contributions.

New MyZubster protocol records

We added a dedicated MyZubster domain with five protocol records:

MZ-001 — Knowledge Layer — canonical record protocol
MZ-002 — Evidence states — from collection to independent review
MZ-003 — Zorgax — AI assistance with human verification
MZ-004 — Development requests — turning patterns into testable work
MZ-005 — Circular economies — verified contribution model
Enter fullscreen mode Exit fullscreen mode

These records document the intended system architecture:

  • AI may structure, retrieve and connect knowledge;
  • AI is not the authority that determines truth;
  • a content hash can establish integrity, not scientific validity;
  • a repeated pattern can become a scoped DevelopmentRequest;
  • a digital event trail does not prove a physical-world outcome without measurement and independent review.

This is the foundation for a knowledge layer that can grow without silently converting proposals into facts.

Circular economies and absorbent hygiene products

We also introduced a Circular economies domain with the AHP-### identifier family:

AHP-001 — Circular Hygiene — evidence pilot framework
AHP-002 — Absorbent-product experience contribution model
AHP-003 — Absorbent materials — test and traceability template
AHP-004 — Circular economies — reproducible pilot catalogue
Enter fullscreen mode Exit fullscreen mode

All four entries are classified as PROTOCOL.

That status is critical. The records define how evidence may be collected and structured; they do not claim that material recovery, safety, environmental impact, product performance or clinical outcomes have already been verified.

For example, AHP-002 establishes a possible contribution model for lived product experience:

lived experience
  → documented observation
  → aggregate pattern
  → DevelopmentRequest
  → prototype or research task
  → independent review
Enter fullscreen mode Exit fullscreen mode

A user report can be valuable input to design. It is not a substitute for clinical evidence, product testing or external validation.

Record inspection

Selecting a card renders a detail panel from the selected record:

function open(id) {
  selected = records.find((record) => record.id === id);

  detail.className = "detail visible";
  detail.innerHTML = `
    <div class="detail-grid">
      <div>
        <div class="meta">
          <span>${selected.id}</span>
          <span>${selected.domain}</span>
        </div>
        <h2>${selected.title}</h2>
        <p>${selected.description}</p>
      </div>
      <ul class="facts">
        <li><b>Evidence state</b>${label(selected.state)}</li>
        <li><b>Domain</b>${selected.domain}</li>
        <li><b>Record ID</b>${selected.id}</li>
      </ul>
    </div>
  `;
}
Enter fullscreen mode Exit fullscreen mode

The current panel intentionally exposes only the available metadata. It does not fabricate source URLs, review results, hashes or relation graphs that are not yet defined by the canonical source.

Verification performed before deployment

The static page JavaScript was parsed before publication:

node -e '
const fs = require("fs");
const source = fs.readFileSync("dist/index.html", "utf8");
const script = source.match(/<script>([\s\S]*?)<\/script>/)[1];
new Function(script);
console.log("JavaScript valid");
'
Enter fullscreen mode Exit fullscreen mode

The VPS-side artifact was then verified before replacing the production file:

grep -n "MZ-001\|AHP-001\|Circular economies" /tmp/knowledge.html
Enter fullscreen mode Exit fullscreen mode

The expected identifiers were present before deployment.

What is not implemented yet

This release is a static product slice, not a complete evidence protocol.

It does not yet include:

  • Markdown or JSON source ingestion;
  • schema validation in CI;
  • record-level source URLs;
  • canonical content hashes;
  • contributor identity verification;
  • consent-aware submission forms;
  • reviewer permissions;
  • relation graph traversal;
  • external validation workflows;
  • physical-world audit evidence;
  • automatic status promotion from PROTOCOL to verified guidance.

Those omissions are deliberate. The interface must not imply capabilities that do not exist.

Next implementation steps

The technical roadmap is:

  1. Store records as Markdown files with YAML front matter.
  2. Add a schema validator for IDs, domains, evidence states and provenance fields.
  3. Generate the record registry and domain counts at build time.
  4. Add stable routes such as /knowledge/AHP-001.
  5. Add source, evidence and relation links.
  6. Implement contribution intake with explicit consent and UNKNOWN defaults.
  7. Add independent review records before exposing any VERIFIED_GUIDANCE state.
  8. Keep the distinction between data integrity and physical/scientific validation explicit in both code and UI.

Conclusion

The Knowledge Explorer is no longer only a list of documents.

It is now a lightweight, static interface for an evidence-aware knowledge model:

share
→ document
→ classify
→ inspect
→ test
→ review
→ improve
Enter fullscreen mode Exit fullscreen mode

The important architectural decision is not the UI framework. It is the refusal to treat a digital record, an AI summary or a contributor claim as verified truth by default.

That boundary is what allows MyZubster to evolve from a catalogue into a traceable knowledge infrastructure.

Top comments (0)