← Research archive
Technical note verified Sep 14, 2026

Trusted Knowledge Indexing Boundary and Private-Data Exclusion

KESPA introduced an authenticated trusted-knowledge indexing path that allows promoted public knowledge to enter the live Chroma retrieval index while blocking internal/private plaintext indexing. MySQL trusted_knowledge remains authoritative and Chroma remains a rebuildable search index; the first promoted trusted record was confirmed live, increasing the clean production index from 423 to 424 cards.

trusted-knowledge indexing privacy chroma security-boundary
MARKDOWN

README.md

2,919 bytes SHA-256 5ce153a1b0e4e058…

KESPA-NOTE-015 — Trusted Knowledge Indexing Boundary and Private-Data Exclusion

Date: 2026-09-14 Status: Verified — live production indexing confirmed Project: KESPA AI / NexLabs Studios

Purpose

After the clean 423-claim production cutover, KESPA needed a controlled way for newly promoted trusted knowledge to enter live semantic retrieval.

The indexing path could not simply accept arbitrary candidate text.

It also had to preserve the privacy boundary between:

  • public promoted knowledge; and
  • internal/private training material.

Indexing contract

The production architecture established:

MySQL trusted_knowledge = authoritative

Chroma forge_cards = rebuildable semantic index

The live Brain added an authenticated:

POST /knowledge/index

for promoted knowledge ingestion.

The path allows public promoted trusted knowledge to enter forge_cards.

It explicitly blocks internal/private plaintext from the public promoted-knowledge Chroma indexing path.

Why that separation matters

A vector database is optimized for retrieval, not for being the canonical trust ledger.

KESPA therefore keeps lifecycle state, provenance, verification, approval, and authoritative knowledge records outside Chroma.

Chroma can then be rebuilt from trusted records if needed.

The index answers:

What trusted information should be retrieved for this query?

It does not decide:

What information deserves to be trusted?

First live validation

The clean production index started at:

423 cards

The first promoted trusted record was indexed:

trusted_knowledge #1

Recorded indexed card:

trusted-knowledge-b645128e-7020-4639-9e3e-7a21aaf36fc8

Production index version:

dev-013-trusted-knowledge-index

Observed result:

  • before: 423
  • after: 424
  • index status: indexed
  • intended-query rank: #1
  • website card counter reflected the live index

Result:

PASS

Privacy boundary

The same architecture keeps internal/private Manual Train material outside the public external-evidence/index path.

That means the system does not solve knowledge growth by flattening every data class into one vector store.

Public knowledge and private/internal material retain different lifecycle rules.

Research significance

This is a small but important control for continuous learning.

Without an explicit indexing boundary, a system can have excellent verification logic and still contaminate live retrieval by allowing unpromoted or private material to bypass the trust lifecycle.

KESPA instead requires:

candidate -> verification -> approval -> promotion -> indexing

for public trusted knowledge.

Limitation

This note proves the production indexing path and its data-class boundary.

It does not claim that one #1 retrieval result is a broad quality benchmark; retrieval effectiveness is evaluated in separate benchmark records.

TEXT

SHA256SUMS.txt

393 bytes SHA-256 3cd71f51ea35c047… 
5ce153a1b0e4e0581231dc6a629db80201df1827494b91f1336a69fd2b4c662b  README.md
8c893e1ebe86e6be40e0b9691b069fde149c715ddfd20f4c7238d381915706ef  note.json
5a0aef890281922a30471b2715337930a40e0b12304f232d856f2d63ad76f96e  metrics.csv
90b67954eed94caad9e0290d2c828a7db3d00dbfd627da90fa072e1b68ff758b  methodology.md
cf0f24846c58262a5a22f369c40ee9bbfbaa965423f65d21ba30294504c2e825  provenance.json
MARKDOWN

methodology.md

974 bytes SHA-256 90b67954eed94caa…

Methodology

Authority separation

MySQL trusted_knowledge remains the authoritative record for promoted knowledge.

Chroma forge_cards is treated as a derived semantic search index.

Promotion-gated indexing

Only knowledge that has already completed the trusted-knowledge promotion path is eligible for the public indexing endpoint.

The indexing operation therefore occurs after verification/approval/promotion rather than at candidate creation time.

Privacy control

Internal/private plaintext indexing is blocked from the public promoted-knowledge path.

This keeps privacy scope separate from public semantic retrieval.

Live validation

The first promoted trusted record was indexed into the clean 423-card production collection.

The live collection count increased to 424, the record's index state became indexed, and the new record ranked first for its intended query.

The website's live card count reflected the same production index count.

CSV

metrics.csv

557 bytes SHA-256 5a0aef890281922a… 
metric,value,unit_or_status
clean_index_before,423,cards
trusted_knowledge_id,1,record
clean_index_after,424,cards
index_status,indexed,status
intended_query_rank,1,rank
website_counter_reflected_live_index,YES,validation
authenticated_knowledge_index_endpoint,YES,control
public_promoted_knowledge_indexable,YES,policy
internal_private_plaintext_public_indexing,BLOCKED,privacy
authoritative_store,MySQL trusted_knowledge,architecture
semantic_index,Chroma forge_cards,architecture
semantic_index_rebuildable,YES,architecture
validation_result,PASS,status
JSON

note.json

2,475 bytes SHA-256 8c893e1ebe86e6be… 
{
    "schema": "kespa.public_technical_note.v1",
    "id": "KESPA-NOTE-015",
    "title": "Trusted Knowledge Indexing Boundary and Private-Data Exclusion",
    "date": "2026-09-14",
    "status": "verified",
    "purpose": "Document the production boundary that separates authoritative trusted knowledge from the semantic retrieval index and prevents internal/private plaintext from entering the public promoted-knowledge indexing path.",
    "indexing_contract": {
        "endpoint_role": "authenticated trusted-knowledge indexing",
        "promoted_public_knowledge_indexable": true,
        "internal_private_plaintext_indexing_blocked": true,
        "authoritative_store": "MySQL trusted_knowledge",
        "semantic_index": "Chroma forge_cards",
        "semantic_index_rebuildable": true
    },
    "runtime_change": {
        "brain_api_version": "v1.1.1-dev",
        "knowledge_index_endpoint": "POST /knowledge/index",
        "authentication_required": true
    },
    "first_live_validation": {
        "clean_index_before": 423,
        "trusted_knowledge_id": 1,
        "clean_index_after": 424,
        "index_status": "indexed",
        "indexed_card_id": "trusted-knowledge-b645128e-7020-4639-9e3e-7a21aaf36fc8",
        "production_index_version": "dev-013-trusted-knowledge-index",
        "intended_query_rank": 1,
        "website_counter_reflected_live_index": true,
        "result": "PASS"
    },
    "privacy_boundary": {
        "public_promoted_knowledge": "eligible for semantic indexing",
        "internal_private_training": "outside public external-evidence/index path",
        "private_plaintext_to_public_chroma": false
    },
    "interpretation": [
        "Trusted knowledge remains authoritative outside the vector database.",
        "Chroma can be rebuilt from canonical trusted records rather than serving as the sole source of truth.",
        "The indexing endpoint creates an explicit promotion boundary instead of allowing arbitrary candidate text to enter retrieval.",
        "Blocking internal/private plaintext indexing prevents the public promoted-knowledge path from collapsing privacy scope into retrieval scope."
    ],
    "limitations": [
        "The first live validation proves the indexing path and privacy boundary, not broad retrieval quality; retrieval quality is measured separately.",
        "An authenticated indexing endpoint still depends on correct upstream authorization and promotion logic.",
        "The public note documents the architecture and live result but does not disclose credentials, request signatures, or private payloads."
    ]
}
JSON

provenance.json

1,007 bytes SHA-256 cf0f24846c58262a… 
{
    "schema": "kespa.public_provenance.v1",
    "research_id": "KESPA-NOTE-015",
    "source_basis": "Historical KESPA production-cutover and trusted-knowledge indexing records from the project changelog/Jira export.",
    "source_observations": [
        "Brain API v1.1.1-dev added an authenticated POST /knowledge/index path.",
        "Public promoted knowledge could enter live forge_cards while internal/private plaintext Chroma indexing was blocked.",
        "MySQL trusted_knowledge remained authoritative and Chroma remained the searchable/rebuildable index.",
        "trusted_knowledge #1 was indexed successfully and the live production count increased from 423 to 424.",
        "The indexed record ranked #1 for its intended query and the website reflected the live 424-card count."
    ],
    "publication_note": "This public note describes the architecture boundary and live validation result. Authentication secrets, private payloads, internal request bodies, and private training content are intentionally omitted."
}