← Research archive
Technical note published Sep 2, 2026

Evidence-Bound Candidate Generation and Provider Rate-Limit Resilience

KESPA's clean pilot generator bound model output to frozen evidence, atomic claim-to-source mappings, retrieval-focused text, contamination guards, and deferred trust. Subsequent provider-pacing changes added rate-header-aware throttling, Retry-After handling, token accounting, and a regression fix for an 8,041-token estimate against an 8,000-TPM limit.

knowledge-factory evidence-bound-generation rate-limits provider-resilience provenance
MARKDOWN

README.md

3,167 bytes SHA-256 f215b7167273eb3d…

KESPA-NOTE-007 — Evidence-Bound Candidate Generation and Provider Rate-Limit Resilience

Date: 2026-09-02 Status: Published technical note Project: KESPA AI / NexLabs Studios

Purpose

Once the 15-topic / 30-card clean pilot had authoritative evidence and an explicit card blueprint, KESPA needed a generator that could use model output without treating model output as truth.

The generator therefore operated under an evidence-bound contract.

Candidate-generation contract

The historical pilot generator included:

  • frozen evidence SHA-256 verification before generation;
  • DeepInfra and local Ollama provider support;
  • a four-card cross-domain canary mode;
  • a strict evidence-only system prompt;
  • atomic claim-to-source mappings;
  • separate focused retrieval_text;
  • candidate schema and length validation;
  • long verbatim-copy detection;
  • regression guards for known synthetic contamination;
  • high-stakes personalized-advice guards;
  • generation audit/failure logs.

Generated candidates remained:

  • verified = false
  • production_ready = false

Trust assignment was explicitly deferred.

Why that boundary matters

A model can synthesize useful prose from good evidence and still introduce unsupported wording.

KESPA therefore separated:

generation -> candidate

from:

verification -> trusted knowledge

The generator's job was to produce a structured, reviewable candidate with evidence mappings — not to declare that candidate correct.

Provider pacing

During later generation work, KESPA added Groq rate-limit awareness:

  • x-ratelimit-* header tracking;
  • rolling TPM pacing;
  • reset-duration parsing;
  • serialized provider calls;
  • Retry-After fallback handling;
  • cumulative token/cost accounting.

The reserved maximum completion budget was reduced:

1400 -> 900 tokens

Local normalization also added:

  • claim punctuation repair;
  • retrieval-text expansion/trimming;
  • 600-character hard floor
  • 700-character target

TPM deadlock defect

A concrete edge case exposed a pacing bug:

  • conservative request estimate: 8,041 tokens
  • provider TPM bucket: 8,000 tokens

If the pacing threshold itself exceeded the entire bucket, the loop could wait forever for a condition that could never become true.

The correction:

  • capped the pacing threshold at the provider's actual TPM limit;
  • kept the provider tokenizer / HTTP 429 response authoritative;
  • retained Retry-After;
  • added an escape when remaining-token headers lacked a usable reset time;
  • added a regression test for the exact 8,041 vs 8,000 condition.

Research significance

This work is less glamorous than a benchmark, but it protects experimental validity.

A large generation run that silently stalls, miscounts failed-attempt tokens, or changes behavior under provider pressure is difficult to reproduce and difficult to cost.

Rate-limit behavior therefore became part of the generation protocol rather than an operational afterthought.

Boundary

No trust was assigned during generation.

No Chroma changes were made.

brain_api.py was not changed by these generator/pacing revisions.

TEXT

SHA256SUMS.txt

393 bytes SHA-256 1d30b4e38148a4c8… 
f215b7167273eb3df13e02615cf05518888041b1fca5a174746d3e16d3c2f458  README.md
54e972abde34dc23b4effd7fde40c1e087caa057d640eaece14307e50d16fd78  note.json
b95384e28189097e904cbe06e9e78f0394e117a7861b0e74cb94fe3b56f263bc  metrics.csv
aab22b4958e633a6a692fab49036e6c9d9a15ad1c8d52f3a3b5668202b25f8a5  methodology.md
e83944d352ef643479baf3504f3241eb1c2af739842bcee9e56e4a3ee88b2332  provenance.json
MARKDOWN

methodology.md

1,080 bytes SHA-256 aab22b4958e633a6…

Methodology

Evidence-bound generation

Before each generation request, the pilot verified the frozen evidence bindings used by the card blueprint.

The model was instructed to stay within the supplied evidence. Generated claims were mapped back to source evidence rather than emitted as an unstructured trusted card.

Validation

Candidate output was subjected to schema, content-length, verbatim-copy, contamination-regression, and high-stakes language checks.

Trust remained deferred regardless of whether generation succeeded.

Provider pacing

Provider headers and retry signals were used to regulate request timing. Calls were serialized where necessary to protect the organization-level TPM budget.

Token/cost accounting included failed validation attempts rather than recording only accepted candidates.

Deadlock regression

The pacing logic was explicitly tested against a request estimate larger than the entire nominal TPM bucket: 8,041 estimated tokens versus an 8,000 TPM limit.

The corrected logic bounded the wait threshold to a realizable value.

CSV

metrics.csv

538 bytes SHA-256 b95384e28189097e… 
metric,value,unit_or_status
pilot_topics,15,topics
pilot_cards,30,cards
cross_domain_canary,4,cards
max_completion_reservation_before,1400,tokens
max_completion_reservation_after,900,tokens
content_hard_floor,600,characters
content_target,700,characters
deadlock_regression_estimate,8041,tokens
deadlock_regression_tpm_limit,8000,tokens_per_minute
generated_verified_default,FALSE,status
generated_production_ready_default,FALSE,status
trust_assigned_during_generation,NO,status
chroma_modified,NO,boundary
brain_api_modified,NO,boundary
JSON

note.json

2,921 bytes SHA-256 54e972abde34dc23… 
{
    "schema": "kespa.public_technical_note.v1",
    "id": "KESPA-NOTE-007",
    "title": "Evidence-Bound Candidate Generation and Provider Rate-Limit Resilience",
    "date": "2026-09-02",
    "status": "published",
    "purpose": "Document the clean-pilot candidate-generation contract and the provider-pacing safeguards added to keep evidence-bound generation reproducible under constrained API token limits.",
    "generation_contract": {
        "pilot_cards": 30,
        "pilot_topics": 15,
        "provider_support": [
            "DeepInfra",
            "local Ollama"
        ],
        "cross_domain_canary_mode": 4,
        "frozen_evidence_sha256_verification": true,
        "strict_evidence_only_prompt": true,
        "atomic_claim_to_source_mappings": true,
        "focused_retrieval_text_generation": true,
        "candidate_length_validation": true,
        "candidate_schema_validation": true,
        "long_verbatim_copy_detection": true,
        "synthetic_contamination_regression_guards": true,
        "high_stakes_personalized_advice_guard": true,
        "trust_assignment_deferred": true,
        "generated_verified_default": false,
        "generated_production_ready_default": false
    },
    "provider_pacing_changes": {
        "groq_rate_limit_header_tracking": true,
        "proactive_rolling_tpm_pacing": true,
        "groq_reset_duration_parsing": true,
        "serialized_groq_calls": true,
        "retry_after_fallback": true,
        "max_completion_reservation_change": "1400 -> 900",
        "failed_validation_token_cost_accounting_fixed": true,
        "cumulative_paid_token_accounting_preserved": true
    },
    "normalization_changes": {
        "local_claim_punctuation_repair": true,
        "local_retrieval_text_expansion_trimming": true,
        "content_hard_floor_characters": 600,
        "content_target_characters": 700,
        "normalization_notes_added_to_candidate_reviews": true
    },
    "deadlock_regression": {
        "problem": "A conservative request estimate could exceed the full TPM bucket and cause the pacing loop to wait indefinitely.",
        "regression_case_estimated_tokens": 8041,
        "groq_tpm_limit": 8000,
        "fix": "Cap the pacing threshold at the actual TPM limit and escape when remaining-token headers do not provide a usable reset time.",
        "groq_tokenizer_or_429_authoritative": true,
        "retry_after_preserved": true
    },
    "architecture_boundaries": {
        "trust_assignment": "none during generation",
        "chroma_changes": false,
        "brain_api_changes": false
    },
    "limitations": [
        "This note documents generator and pacing mechanics, not a final candidate-quality benchmark.",
        "Provider behavior and rate-limit headers can change over time; the recorded logic reflects the 2026-09 implementation.",
        "Supporting a provider does not mean provider output is trusted; trust remained deferred until later verification.",
        "The public note omits credentials, private prompts beyond the methodological description, raw model outputs, and internal source code."
    ]
}
JSON

provenance.json

999 bytes SHA-256 e83944d352ef6434… 
{
    "schema": "kespa.public_provenance.v1",
    "research_id": "KESPA-NOTE-007",
    "source_basis": "Historical KESPA changelog/Jira export supplied for public research reconstruction.",
    "source_observations": [
        "The evidence-bound pilot generator supported DeepInfra and local Ollama, verified frozen evidence hashes, used atomic claim-to-source mappings, and deferred all trust assignment.",
        "Groq generation was later made rate-header-aware with rolling TPM pacing, reset parsing, serialization, Retry-After fallback, and improved token/cost accounting.",
        "A pacing deadlock was fixed for the specific 8,041-token estimate versus 8,000-TPM condition.",
        "No Chroma changes and no brain_api.py changes were recorded for these revisions."
    ],
    "publication_note": "This public note publishes generator/pacing methodology and aggregate configuration values only. Credentials, raw prompts/model outputs, private implementation code, and provider secrets are intentionally omitted."
}