- Tenrec Intent Router
- Relationship to the Veritiana Prompt Classifier
- What it returns
- Model architecture
- 100 task archetypes
- Local inference
- Feature contract
- Reference evaluation
- Reproducing training
- Adaptive use inside Tenrec
- Why this is separate from the Memory Router
- Repository contents
- Appropriate uses
- Out-of-scope uses
- Privacy
- License
- Citation
- Relationship to the Veritiana Prompt Classifier
Tenrec Intent Router
A tiny local intent classifier that maps a software-engineering goal to one of 100 inspectable Tenrec task archetypes before agent execution begins.
Tenrec starts from intent instead of asking a large model to invent an execution plan from scratch. The released router is the first recognition stage of the Tenrec Planner:
User goal
β local feature extraction
β IntentNet ONNX classifier
β 100 task archetypes
β Project Inspector
β architecture recommendation
β plan
β short-lived worker colony
The classifier does not choose a framework, database, cloud, or implementation stack. It identifies the task archetype. Tenrec's deterministic Project Inspector and Architecture Selector then constrain the plan using facts from the actual repository.
Relationship to the Veritiana Prompt Classifier
The existing Veritiana Prompt Task & Complexity Classifier is a broad Level-0 recognition layer:
prompt β task family + complexity
Tenrec adds a narrower software-execution Level-1 layer:
software goal β one of 100 concrete work archetypes β repository-aware planning
They can be used independently or composed.
What it returns
Example:
python examples/python/classify.py \
"Add OAuth2 PKCE authentication to this FastAPI project"
Output structure:
{
"prediction": {
"recipe_id": "auth_oauth_oidc",
"title": "OAuth/OIDC authentication",
"confidence": 0.0,
"neural_confidence": 0.0,
"lexical_confidence": 0.0
},
"alternatives": []
}
Confidence values depend on the supplied goal. The public runtime combines the neural probability with an inspectable lexical signal. The ONNX file itself emits the 100-class neural probability distribution.
Model architecture
The input is a fixed float32[1,384] vector.
Feature extraction uses signed hashing over:
- normalized word tokens;
- adjacent word bigrams;
- BLAKE2b-derived feature indices;
- L2 normalization of the final vector.
The neural head is deliberately small:
raw goal
β
hashed feature vector float32 [1,384]
β
MatMul + bias
β
Softmax float32 [1,100]
The released model.onnx is approximately 151 KB and uses ONNX opset 13.
100 task archetypes
recipes.json contains exactly 100 transparent task recipes. Categories in the bootstrap library include:
- maintenance;
- testing and quality;
- security;
- backend and frontend;
- integrations;
- data;
- DevOps;
- observability;
- documentation;
- project tooling.
Each recipe contains:
id
category
description
keywords
examples
inspection requirements
compatible architecture patterns
typical work units
validators
constraints
The recipes are intentionally inspectable rather than hidden inside an LLM system prompt.
Local inference
Create a Linux/WSL environment:
python -m venv .venv
source .venv/bin/activate
pip install -r requirements-inference.txt
python infer.py "Repair the failing authentication tests"
onnxruntime is preferred when installed. The included reference implementation also supports NumPy inference from weights.npz, which is useful for testing the exact feature contract without an ONNX runtime.
Feature contract
Raw text cannot be sent directly to model.onnx. Use features.py to create the 384-dimensional input vector.
The public contract is:
input: float32 [1,384]
output: float32 [1,100]
Class order is defined by labels.json.
Reference evaluation
The bundled reference model records:
| Metric | Result |
|---|---|
| Classes | 100 |
| Bootstrap training examples | 400 |
| Synthetic held-out examples | 100 |
| Top-1 accuracy | 0.89 |
| Top-3 accuracy | 0.98 |
These numbers come from the fixed bootstrap recipe examples: four examples per archetype are used for training and the fifth is held out. They are an internal synthetic regression benchmark, not an independently established real-world accuracy claim.
The classifier should therefore be treated as a routing signal. Tenrec uses project inspection, architecture constraints and validation after classification rather than assuming the classifier is always correct.
Reproducing training
python -m venv .venv
source .venv/bin/activate
pip install -r requirements-training.txt
python train.py --recipes recipes.json --output-dir reproduced-output --epochs 260
The reproduction script writes:
model.onnx
weights.npz
labels.json
recipes.json
metrics.json
Numerical scores can vary if training configuration is changed. The shipped reference weights and checksums are recorded in SHA256SUMS.
Adaptive use inside Tenrec
The full Tenrec runtime can record validated successful runs as project-local feedback. Retraining remains gated: a candidate router is not promoted if it regresses beyond the configured threshold on the fixed 100-archetype regression set.
This is project-specific adaptation. It is not evidence that successful execution automatically gives perfect intent labels.
Why this is separate from the Memory Router
Tenrec uses two learned routing problems:
Intent Router β what kind of work is this?
Memory Router β what should this worker know right now?
The Intent Router has a generic bootstrap checkpoint and is released here. The Memory Router is trained and maintained per project, so Tenrec does not present one project-independent memory checkpoint as universally useful.
Repository contents
README.md
model.onnx
weights.npz
labels.json
recipes.json
metrics.json
config.json
training-config.json
features.py
model.py
infer.py
train.py
onnx_export.py
requirements-inference.txt
requirements-training.txt
requirements-upload.txt
LICENSE
CITATION.cff
SHA256SUMS
assets/
tenrec-architecture.png
examples/
python/classify.py
upload_to_hub.py
Appropriate uses
- local software-task intent classification;
- pre-planning signals for coding or software-maintenance agents;
- selection of an inspectable task recipe;
- research and prototyping around small pre-LLM routing models;
- local plan preview where a remote LLM should not be required just to identify the task class.
Out-of-scope uses
Do not treat the router as:
- a universal software architect;
- proof that an implementation plan is correct;
- a security authorization layer;
- a code-quality evaluator;
- a replacement for repository inspection;
- a replacement for deterministic validation;
- a benchmark demonstrating real-world agent success.
Privacy
Feature extraction and inference can run locally. The model itself does not require prompt content to be transmitted to a remote service. Integrators remain responsible for any surrounding services they add.
License
MIT. See LICENSE.
Citation
@software{tenrec_intent_router_2026,
title = {Tenrec Intent Router},
author = {Veritiana AI},
year = {2026},
version = {0.2.0},
url = {https://huggingface.co/veritiana-ai/tenrec-intent-router}
}
- Downloads last month
- -
