Technical note verified Sep 4, 2026

Compute-Aware Model Routing and Telemetry Foundation

KESPA validated its local model registry, routing infrastructure, persistent telemetry, metrics endpoint, RTX 3070 instrumentation, and Admin controls on the actual KESPA machine. A subsequent routing-policy correction separated technical-learning requests from coding requests while preserving local-first execution.

model-routing telemetry compute-efficiency local-ai instrumentation

MARKDOWN

README.md

2,480 bytes SHA-256 92b602f01c893447…

KESPA-NOTE-006 — Compute-Aware Model Routing and Telemetry Foundation

Date: 2026-09-04 Status: Verified — actual KESPA machine Project: KESPA AI / NexLabs Studios

Purpose

Before KESPA could make defensible claims about adaptive inference or compute efficiency, it needed to measure its own runtime and make routing behavior controllable.

This milestone validated the infrastructure for that work.

Validated runtime components

On the actual KESPA machine, the historical record reports:

Brain API: PASS
Models Admin: PASS
Telemetry Admin: PASS
persistent telemetry: PASS
metrics endpoint: PASS
RTX 3070 telemetry: PASS

Production Chroma was not modified.

Database impact was limited to configuration additions.

Private routing remained local by default, and no new request-time external-provider dependency was added.

Why routing configuration mattered

An early routing rule treated broad technical terms such as docker as coding intent.

That produced a useful failure case:

a Docker explanation request could be misrouted as coding;
an actual Python implementation request should still route as coding.

The coding-keyword policy was narrowed and then validated:

Docker explanation -> learn / instant — PASS
Python implementation request -> build / coding — PASS
telemetry requests -> 3/3 successful

Research significance

This was infrastructure work, but it removed two major experimental problems.

First, KESPA could now persist runtime telemetry instead of relying on ad hoc observations.

Second, routing behavior could be changed through configuration/Admin policy rather than being inseparable from model/runtime mechanics.

That separation became important for later work on:

adaptive inference;
escalation policy;
latency and energy measurement;
role-specific model selection;
future GPU/model swaps.

Hardware boundary

The machine used an NVIDIA RTX 3070.

At this point, the single-GPU setup supported one resident primary model, so multiple logical model roles did not yet mean multiple simultaneously resident specialized models.

That limitation is part of the research record rather than something to hide.

Boundary

This milestone did not modify production Chroma and did not add a new cloud dependency to normal request handling.

It established the instrumentation and routing-control layer used by later KESPA experiments.

TEXT

SHA256SUMS.txt

393 bytes SHA-256 98476dd664e603c4…

92b602f01c8934473645bcb669c1d8a6a52c35ee4b1bd56623682575fa9dcd7d  README.md
a76bc4dc93f0b7134a0433255e5936fc55a06edd155d1d408fa17899bfe7c265  note.json
62400afc35dc1ba686699ed79b879e1bfb4b25ce5b198bb6616bdb53f40a2e08  metrics.csv
9aef21ef181c066cc59fbf7205e595389cd68343feb7c4be0a5aa34195d1ccb2  methodology.md
dfb87e1ec38d31e2780b8932051166801569e36674869d3cf9454d2db71db01f  provenance.json

MARKDOWN

methodology.md

853 bytes SHA-256 9aef21ef181c066c…

Methodology

Infrastructure validation

The model registry, routing infrastructure, telemetry persistence, metrics endpoint, and Admin surfaces were exercised on the actual KESPA machine.

The source record marks the Brain API, Models Admin, Telemetry Admin, persistent telemetry, metrics endpoint, and RTX 3070 telemetry as passing.

Routing correction

A routing defect was observed in which broad technical keywords could classify educational questions as coding.

The correction narrowed the coding-intent keyword set while leaving runtime mechanics unchanged.

Validation then checked one educational request, one implementation request, and three telemetry requests.

Experimental boundary

The purpose of this work was to make later compute/routing experiments measurable and tunable.

It did not itself claim improved answer quality.

CSV

metrics.csv

477 bytes SHA-256 62400afc35dc1ba6…

metric,value,unit_or_status
brain_api,PASS,validation
models_admin,PASS,validation
telemetry_admin,PASS,validation
persistent_telemetry,PASS,validation
metrics_endpoint,PASS,validation
rtx_3070_telemetry,PASS,validation
docker_explanation_route,learn / instant,PASS
python_implementation_route,build / coding,PASS
telemetry_requests,3/3,successful
production_chroma_modified,NO,boundary
request_time_external_provider_dependency_added,NO,boundary
primary_gpu,RTX 3070,hardware

JSON

note.json

2,448 bytes SHA-256 a76bc4dc93f0b713…

{
    "schema": "kespa.public_technical_note.v1",
    "id": "KESPA-NOTE-006",
    "title": "Compute-Aware Model Routing and Telemetry Foundation",
    "date": "2026-09-04",
    "status": "verified",
    "purpose": "Document the validated runtime infrastructure that made later adaptive-compute experiments measurable: model registration, role-based routing, persistent telemetry, hardware metrics, and Admin-configurable routing policy.",
    "validated_components": {
        "brain_api": "PASS",
        "models_admin": "PASS",
        "telemetry_admin": "PASS",
        "persistent_telemetry": "PASS",
        "metrics_endpoint": "PASS",
        "rtx_3070_telemetry": "PASS"
    },
    "routing_policy_correction": {
        "problem": "Broad coding keywords caused technical-learning questions such as Docker explanations to route as coding tasks.",
        "change": "Narrowed coding-intent keyword configuration.",
        "validation": [
            {
                "request": "Docker explanation",
                "expected_route": "learn / instant",
                "result": "PASS"
            },
            {
                "request": "Python implementation request",
                "expected_route": "build / coding",
                "result": "PASS"
            },
            {
                "telemetry_requests": "3/3",
                "result": "PASS"
            }
        ]
    },
    "architecture_boundaries": {
        "production_chroma_modified": false,
        "database_change": "configuration additions only",
        "private_routing": "local by default",
        "new_request_time_external_provider_dependency": false
    },
    "hardware_context": {
        "gpu": "NVIDIA RTX 3070",
        "operational_constraint": "one resident primary model on the then-current single-GPU setup"
    },
    "research_relevance": [
        "Persistent telemetry created the measurement substrate needed for later latency, energy, routing, and escalation experiments.",
        "Admin-configurable routing allowed policy tuning without tying research behavior permanently to source-code changes.",
        "Separating learning intent from coding intent reduced an observed routing-confound before later system benchmarks."
    ],
    "limitations": [
        "At this stage one physical RTX 3070 supported one resident primary model, so model-role differences were primarily routing/configuration semantics rather than simultaneous multi-model specialization.",
        "This note documents infrastructure validation, not a standalone quality benchmark.",
        "Later routing and adaptive-inference experiments are documented separately."
    ]
}

JSON

provenance.json

1,032 bytes SHA-256 dfb87e1ec38d31e2…

{
    "schema": "kespa.public_provenance.v1",
    "research_id": "KESPA-NOTE-006",
    "source_basis": "Historical KESPA changelog/Jira export supplied for public research reconstruction.",
    "source_observations": [
        "Brain model registry, routing infrastructure, telemetry, and Admin validation passed on the actual KESPA machine.",
        "Persistent telemetry, metrics endpoint, and RTX 3070 telemetry were recorded as PASS.",
        "A routing-policy correction narrowed coding keywords so Docker explanation requests routed as learn/instant while Python implementation requests routed as build/coding.",
        "Three of three telemetry requests succeeded after the routing change.",
        "Production Chroma remained unchanged and no new request-time external-provider dependency was added."
    ],
    "publication_note": "This public note contains aggregate validation and architecture information. Private configuration values, telemetry payloads, credentials, internal source code, and Admin implementation details are not republished."
}