Download the 1.13.1 published whitepaper

Whitepaper contents
  1. Implementation whitepaper and developer guide
  2. Published 1.13.1 capabilities and availability
  3. Current evaluation evidence and limits
  4. Licensing and enterprise evaluation
  5. 1 Executive overview
  6. 2 Suitable workflows and boundaries
  7. 3 Install and run the packaged examples
  8. 4 Ingestion and the first Python integration
  9. 5 Execution paths and the six retrieval channels
  10. 6 Node reference and request controls
  11. 7 Strict evidence mode
  12. 8 Consume results as contracts
  13. 9 Evidence-backed documents and verified sentence generation
  14. 10 Financial component example
  15. 11 HTTP service and authorization
  16. 12 Python API reference
  17. 13 Historical evidence and reproducibility
  18. 14 Deployment checklist and next steps
  19. References and implementation authority

CPU-LLM: Evidence-Based AI Engine

Answer questions from your documents and explicit rules, with source evidence and CPU-first execution.

Implementation whitepaper and developer guide

Product: cpu-llm 1.13.1 Author: Amin Parva, Independent Engineer Date: November 11, 2026 Edition: 1.13.1 published release Audience: application developers, technical evaluators and engineering leads

This paper explains how to install cpu-llm, ingest records, select its execution paths, interpret results and integrate its Python and HTTP interfaces. It documents implemented behavior and engineering evidence. It is not a peer-reviewed clinical study, security certification or guarantee of factual correctness. Source code and executable examples remain the implementation authority. References at the end link to the version, contracts and saved runs.

Published 1.13.1 capabilities and availability

CPU-LLM 1.13.1 is published on PyPI. Install with python -m pip install "cpu-llm==1.13.1". The GitHub release wheel and source distribution match the PyPI SHA-256 digests. The pypi-v1.13.1 release tag resolves to build source deba0b0.

Published package: https://pypi.org/project/cpu-llm/1.13.1/

Release and matching artifacts: https://github.com/insightitsGit/cpullm/releases/tag/pypi-v1.13.1

CPU-LLM is an Evidence-Based AI Engine for CPU-first, source-backed document answers, auditable deterministic checks and cross-domain research. Use it for evidence-based document question answering, cited document answers and financial covenant verification against explicit supplied rules. Citations identify evidence; they do not authenticate source truth.

Document answers and operations

Cited weight and color lookups and exact location quotes retain source evidence. Coordinated questions are answered independently. Possession joins keep both premises. Missing evidence produces abstention rather than an invented answer. Grounded bullet summaries render selected sentences as separate items. Conservative typo repair uses recognized question words and corpus-backed vocabulary, while leaving source quotations intact. This is bounded repair, not a guarantee for arbitrary misspellings.

The authenticated service supports file-backed credential reload at authentication time. Atomically replace the file to remove or revoke a credential. Optional mutation audit logging uses --audit-db and --audit-retention-days. These controls require deployment-specific identity, retention and operational review.

Optional external model boundary

The optional external LLM fallback is off by default. An application-provided adapter can handle eligible guard-approved, unsupported standalone requests with an API key or OIDC access-token callback. Strict Evidence Mode bypasses this fallback. Clarification, insufficient evidence, batches, session turns and specialist workflows stay on their existing paths.

The adapter receives the original prompt and credential, without retrieved passages or session history. Successful external text is labeled external_unverified, has empty evidence and carries a visible verification notice. Missing credentials or provider errors preserve the original CPU-LLM response. The application adapter must enforce its own timeout and raise on authentication failure. External text is not verified evidence.

Consumer configuration: https://github.com/insightitsGit/cpullm/blob/main/docs/library-consumer-guide.md#optional-external-llm-fallback

Research routes remain distinct from evidence

CrossDomain research selects 2-7 knowledge bases. Constraint Check compares structured numeric claims and explicit constraints. Invention output remains a labeled hypothesis. The leptogenesis example is an illustrative bounded numerical scan: findings are conditional on the model, inputs and constraints, not an established discovery or validation of a physical theory.

Single-pass ingestion, scoped chunk inventory and confirmed deletion support document operations. Deletion requires team admin authorization. Ordinary requests enter the guarded retrieval graph; explicit document, invention, CrossDomain and management requests can select separate routes before graph entry. Strict evidence policy disables invention, CrossDomain and Constraint Check routes.

Prompt examples and execution routes

Trigger precedence and flags: https://github.com/insightitsGit/cpullm/blob/pypi-v1.13.1/docs/prompt-flag-map.md

Tagged prompt addendum: https://github.com/insightitsGit/cpullm/blob/pypi-v1.13.1/docs/whitepapers/prompt-routing-addendum.md

Current evaluation evidence and limits

On a recorded clean checkout of 7adf319, the revised synthetic request suite passed 460/460 scored rows across dense and resonance retrieval, including 278/278 expected answers and 86/86 expected abstentions. The configured scorer flagged zero false assertions. Three fixtures changed from the prior suite, covering overview specificity, equivalent proof and grounded partial drafts. This is a scoped request-pipeline regression metric, not universal accuracy or an unchanged comparison with the prior suite.

A separate harbor fixture initially scored 20/24 and exposed a color-vocabulary gap for ochre in both retrieval configurations. After the vocabulary fix, the same fixture replayed at 24/24. An expanded harbor regression replay with four typo prompts passed 32/32 across both retrieval configurations. These are regression replays after a fix, not fresh independent holdout scores.

Inspect displayed replies for duplicate text and list structure as well as fields read by the scorer. These synthetic results are not certification, clinical validation, a production readiness guarantee or a comparison to hosted models.

Public benchmark notes: https://github.com/insightitsGit/cpullm/blob/main/docs/benchmark-validity-review.md#recorded-results

The earlier evaluation edition preserves older installed-wheel, strict-evidence, specialist and operations receipts with their original scope. Those results are not pooled into the revised request-suite score.

Licensing and enterprise evaluation

The Apache-2.0 package is free for individuals and small teams. Organizations of any size can self-manage it under that license. Paid enterprise pilots, integration and support are negotiated with Amin Parva through Insight IT Solutions; contact https://www.insightits.com/#contact to discuss scope. There is no implied mandatory enterprise license.

Bundled WikiText data retains its separate CC BY-SA 3.0/GFDL terms. Review the package's third-party notices and prepare database and encoder assets for offline deployments.

1 Executive overview

cpu-llm is an Apache-2.0 Python library for CPU-first document question answering and explicit rule checks. It combines a trained retrieval projection, a pretrained sentence encoder, PostgreSQL/pgvector, symbolic source connections, conditional graph stages and bounded response construction. Applications embed the library or place its authenticated HTTP entry point behind their own service infrastructure. It can support self-hosted document search and evidence-backed question answering without requiring an unrestricted generative decoder for every answer.

The central integration decision is which response path a request needs. Strict evidence mode returns recognized source quotations, explicit evidence chains, bounded exact calculations or nonanswers. The ordinary graph supports additional producers such as supplied-field finance checks, simple event frames, summaries and layouts. Ordinary document replies can publish verified technical prose; the single-fact path offers a companion. A reviewed built-in pack handles basic social requests separately from document knowledge.

These paths have different contracts. A quotation is not a verification of its source. A calculation is not a clinical recommendation. A generated companion is not a verbatim quotation. A social response is not retrieved evidence. Applications should preserve those distinctions in their interface and logs.

The name does not imply that cpu-llm is a general replacement for ChatGPT or every RAG system. It targets inspectable, bounded document and rule workflows. The published release does not establish 100 percent accuracy, clinical safety, universal contradiction detection, or superiority over hosted LLMs.

Document verification for enterprise workflows

For private credit covenant monitoring, supply the governing threshold, comparison direction and rounding policy, then inspect the deterministic financial calculation. A source hash can establish consistency with a stored passage, not whether that passage is authoritative. The Luma refusal, six-place LedgerCovenant calculation and Helios composition below illustrate distinct contracts.

A generative RAG application can add citations and calculators; without an enforced verification layer its generated wording needs separate checks. CPU-LLM strict mode selects supported quotations, executes recognized calculations or declines. Ordinary verified document composition has a different contract. This compares execution behavior, not benchmark superiority, compliance or cost.

Historical hardening in 1.11.2

Ordinary learned-writer fallback requires explicit CPU_LLM_ALLOW_LEARNED_WRITER=1 and compatible assets. Strict mode still bypasses it. Explicit child-safety or grade controls warn that the pipeline does not apply a gate; the standalone gate is unvalidated.

HTTP rejects unsupported framing, caps bodies at 1 MiB and applies a 10-second socket inactivity timeout. This is neither a total request deadline nor a substitute for TLS, identity controls or a deployment gateway.

Strict comparisons recognize bounded bare numeric equivalence and explicit mass/volume unit aliases. Different dimensions, negations and qualifiers are not collapsed; original quotations and proofs remain available.

For on-premises CPU deployment, prepare Python dependencies, PostgreSQL/pgvector and encoder assets. An air gap additionally requires operator-enforced network isolation. Code is Apache-2.0; bundled WikiText-2 data carries separate CC BY-SA 3.0/GFDL terms.

PyPI published the earlier 1.11.2 candidate. Both distribution hashes match the publication receipt. All 113 wheel Python files and the source archive’s Python sources match the validated implementation. The public wheel differs from the final candidate in METADATA and RECORD: its README retains the historical 1.11.1 test count and two relative badge links. The prepared 1.11.2 default source suite completed in 116.81 seconds: 925 passed, 56 skipped, three existing expected failures and six existing NumPy warnings. A fresh native PostgreSQL database resolved the earlier connection stall. The skips include 54 disabled opt-in integration cases and two missing optional extractor checkpoints. Separately, 72 focused checks passed. The exact prepared wheel installed and passed pip check; all 113 packaged Python files matched source after newline normalization. Both distributions passed strict Twine checks, and the wheel includes the reviewed README metadata and third-party notice. These are engineering checks, not a full-live benchmark or clinical validation. These tests are not clinical validation or compliance certification. Docker startup on the maintainer's host remains unverified.

Hardening specification: https://github.com/insightitsGit/cpullm/blob/b8a7cbe/docs/audit-hardening-spec.md

Commercial pilots: discuss covenant verification, on-premises deployment or enterprise workflow adapters with Insight IT Solutions at https://www.insightits.com/#contact .

2 Suitable workflows and boundaries

Document assistance. Retrieve supported facts from manuals, policies and records; show the original supporting text; ask for missing intent or retain a nonanswer when the contract cannot be satisfied. Documents must be ingested before the tenant can answer questions about them.

Healthcare and pharmacy demonstrations. The included fictional records exercise label strengths, ingredients, storage, recorded diagnoses and allergies, conflicting labels, missing information and refusal of unsupported treatment questions. A recorded-diagnosis lookup does not diagnose from symptoms. An arithmetic comparison with a supplied limit does not decide a safe dose. Authoritative sources, intended-use validation and independent clinical review are still required for any clinical decision-support claim.

Financial review support. RefundProof, LedgerCovenant and Ledgerlock validate recognized caller-supplied fields and policies. They can make numeric inputs, decision traces and refusals inspectable. Source-authority labels in the request are inputs, not independent authentication of financial documents. These checks are not tax/legal advice or automatic authority to recover money or declare a default. The library's components are not the same deployment as the website's separate hosted financial products.

Application conversation. Greetings, identity, wellbeing, capabilities, thanks, farewells and limitation questions receive original reviewed responses. This improves basic interaction without importing another assistant's identity or treating a dialogue corpus as medical knowledge. It does not supply arbitrary world knowledge or unrestricted conversational reasoning.

3 Install and run the packaged examples

Python 3.11 or newer is required. The release validation used Windows and Python 3.12.10; it did not freshly execute every supported operating system/version.

python -m pip install "cpu-llm==1.13.1"
python -m pip check
cpu-llm-demo --help

Configure PostgreSQL with pgvector and set VECTORPRISM_PG_DSN to the appropriate database. The wheel contains the trained VectorPrism projection and demo data. The pretrained sentence-transformers/all-mpnet-base-v2 encoder assets must be downloaded on first use or cached beforehand. Installation does not start the database or ingest a corpus. First startup includes asset loading; there is no universal startup, throughput, memory or training-time guarantee.

cpu-llm-demo healthcare --out healthcare-demo-new-run
cpu-llm-demo conversation --out conversation-demo-new-run

Each output directory must be new. These commands create isolated namespaces, ingest packaged fictional records and save actual responses and expected-result checks. They work from an installed package without Git or repository paths. No model retraining is needed. Once model assets are cached, offline settings can be used; dependency provisioning and deployment egress controls remain the operator's responsibility.

HF_HUB_OFFLINE=1
TRANSFORMERS_OFFLINE=1

The lines above name environment settings, not portable shell assignment syntax. For example, PowerShell uses $env:HF_HUB_OFFLINE = '1'. Offline operation requires the assets to exist already. Optional spaCy parsing uses the prompt_nlp extra and a separately installed en_core_web_sm model. Coreferee, FastCoref and optional decoder checkpoints also require their own compatible assets. They are not bundled in the small wheel.

Prepare an offline encoder and database

On a connected machine, set HF_HOME and HF_HUB_CACHE before Python imports, populate the encoder cache, transfer it and run the offline checker. Optional FLAN-T5 and parser assets require separate preparation. Caching the encoder does not retrain the bundled projection. https://github.com/insightitsGit/cpullm/blob/c2de454/docs/offline-setup.md

Wait for database readiness and verify the vector extension. Match VECTORPRISM_PG_DSN to the actual database, user and mapped port, including alternate ports. Initialization scripts run on a fresh volume; changing Compose settings does not reinitialize an existing database. https://github.com/insightitsGit/cpullm/blob/c2de454/docs/development-database.md

4 Ingestion and the first Python integration

Construct an appliance inside a guarded main() on Windows because its worker pool starts child processes. Reuse an appliance and close it with a context manager. Construction loads the retrieval stack and connects to storage; it is not a lightweight stateless function call.

from cpu_llm.documents import SourceDocument
from cpu_llm.pipeline import Appliance
from cpu_llm.access import CallerContext

def main():
    with Appliance(namespace="paper_demo", strict_evidence=True,
                   prompt_backend="rules") as app:
        receipt = app.ingest(SourceDocument("manual", (
            "The material of Example Device is steel.",
        )))
        caller = CallerContext.make(
            app.tenant_id, "reader", ["manual-p"]
        )
        result = app.ask(
            "What is the material of Example Device?",
            caller=caller,
        )
        print(receipt["ids"])
        print(result["answer_status"])
        print(result["reply"]["text"])
        print(result["answer_evidence"])

if __name__ == "__main__":
    main()

The source name produces paragraph IDs such as manual-p0001. Caller scopes can authorize an exact document ID or a source prefix such as manual-p. Source boundaries are explicit; arbitrary string-prefix similarity is not an authorization rule. Files and supplied paragraphs can also carry structured connections into the source-backed graph.

The appliance supports structured SourceDocument inputs and recognized file formats, including text/Markdown, HTML, PDF, Word, spreadsheets and EPUB. This does not establish support for scanned-page OCR, every table layout or arbitrary clinical document interpretation. Evaluate the actual reader output before using it as a source. Reingestion updates the source's stored paragraphs and connections; it is not retraining the encoder or a general sentence generator.

Named namespaces map to normalized tenant/schema names and cache folders. Different raw names can normalize to the same slug. Provision canonical tenant identities rather than accepting arbitrary names as proof of isolation. Use a stable, deliberately separated working directory/cache for a deployment and database combination; database state and graph/cache state are distinct.

5 Execution paths and the six retrieval channels

The request boundary checks caller scope and guards raw input. With small talk enabled, complete reviewed social phrases use a built-in response. A leading greeting before a substantive request can be removed with an explicit provenance record; the remaining request is retained. Strict mode then follows its separate evidence path. Ordinary requests proceed through planning and the graph.

The ordinary graph's core progression is:

guard -> retrieve -> resonate -> six channel readings
      -> catalog -> detail -> spans -> think -> cognize
      -> grammar -> shine -> requested optional stages
      -> model01 -> reply -> optional discover

Conditional branches and delivery holds matter; this diagram is not a promise that every optional stage runs. Final response judgment/repair is part of the public request pipeline. The optional stylistic output subgraph and final layout rendering are separate from the core graph.

The six channels are dense, relational, disentangled, hyperbolic/taxonomy, identity, and causal/time. They provide retrieval and relation signals, not independent proof of a claim. The shipped projection enables dense and identity heads; symbolic connections in other channels do not mean all six projection heads are trained and enabled. Epistemic/source support is separate metadata. Connections are stored alongside vectors rather than recoverable as a complete word network from vector coordinates alone.

Strict lookup uses a scoped SQL snapshot and recognized literal source forms; its conflict check is not a vector top-k vote. Curated tone features and the ten output tone preferences are a different system from these six retrieval channels. Adding a channel score or tone weight never creates a missing fact.

6 Node reference and request controls

Developers normally use ask and its options, not direct calls to internal graph nodes. The implementation registers 27 core nodes: 21 named stages plus six channel-reading nodes. The inventory below describes responsibility, not a standalone public API guarantee for each internal function.

Core and interpretation stages

Conditional stages and delivery

The pre-graph conversation.reply and strict_evidence.answer paths are outside that 27-node graph. The opt-in output stages stylistic -> style_verify are also separate. Not all stages are automatically invoked for every question.

deep, math, finance and discover have explicit Python switches. Recognized prompt forms can request comparisons, summaries, lists, sources, explanations and frames. A long-response request adjusts retrieval/delivery budgets; it does not automatically request the deep-search node. Presentation flags select built-in tables, bullets, numbered lists or reports after judgment. They do not permit missing claims to be invented to fill a length target.

The flag registry maps each supported flag to its consumer and enforces optional node routing. Advanced payment, authority, objective, hypothesis and causal-graph inputs require the corresponding typed contracts; a keyword alone is not a validated business or clinical decision procedure.

7 Strict evidence mode

Enable per request with strict_evidence=True, with the strict HTTP header/body flag, or with a standalone first-line [strict-evidence] prompt control. A constructor or service strict floor cannot be disabled by a weaker request. The ordinary realization="deterministic" setting by itself is not a reliable disable switch for the separate automatic fact-bridge fallback. Strict mode bypasses that learned path and the ordinary generation/specialist nodes.

Supported strict forms include a single What is the <attribute> of <entity>?, up to eight bounded questions, explicit attribute lists and up to 32 recognized direct attributes in an overview. A one-hop join requires an explicit membership and an explicit universal rule; a class average does not license an individual fact. A complete ambiguous/missing task is retained as a nonanswer rather than silently removed from a batch.

Recognized source forms include canonical attribute statements, possessive statements, has constructions and for variants. Whole chunks remain atomic so a qualifier in a following sentence is not silently discarded. Recognized negation, uncertainty and conflicting values withhold the slot. Other prose contradictions may be missed. Exact scalar mass, volume and time equivalence is supported for the specified unit symbols; arbitrary dose conversions, ranges, compound units and clinical equivalence are not inferred.

One SQL snapshot considers at most 10,000 authorized time-valid chunks and eight million text characters. Overflow refuses to select a factual answer. as_of selects stored historical validity, not proof that a statement remains medically current outside the database. scan_complete describes the bounded database scan, not completeness of medical knowledge or semantic contradiction coverage.

Strict arithmetic supports bounded explicit addition, subtraction and multiplication, plus recognized same-unit greater-than comparisons. A scalar source value can be multiplied only after unambiguous supported retrieval. Conflicting or uncertain source inputs do not produce a calculation. The result records operands/operator/value/unit and is labeled arithmetic, not treatment advice. There is no arbitrary expression execution or clinical dosing policy.

Strict requests are stateless across turns. A unique earlier named entity in the same bounded batch can resolve of it; general cross-turn reference resolution is not enabled. Version 3 additionally types approved social turns as builtin_conversation, with empty document evidence and no clinical audit. Disable small_talk if a deployment requires only factual envelopes.

8 Consume results as contracts

reply.text is display text, not a universal truth/correctness certificate. Read the outcome, evidence, per-task results and producer-specific fields.

Strict proofs contain document ID, literal quote, character offsets and a SHA-256 hash of the complete stored chunk. Offsets use Python string positions with an exclusive end, not UTF-8 byte positions. Ordinary evidence can instead use source span records. Preserve those distinctions. An unkeyed hash is a content fingerprint, not a publisher signature, clinical endorsement or durable audit log. Retain the response and matching source version in the application's own audit process when required.

Do not retry a held medical question by stripping safeguards or enabling a learned fallback. A quotation can be accurate to an incorrect source. A source scope check can succeed while the underlying document is obsolete. Applications own source quality and the authorized decision workflow.

9 Evidence-backed documents and verified sentence generation

Separate facts from expression

The knowledge base supplies facts and source records. A user's request for a friendly tone supplies a presentation preference. CPU LLM separates that explicit preference from the topic before evidence selection; the source documents do not need matching tone words or finished sentences. API style settings override prompt tone. Strict evidence settings disable generated wording. The system does not infer an emotional state or remember tone across requests.

Evidence-backed document planning

Report, article and design-document requests select a shared plan for genre, topic, sections, length and output format. Evidence comes from a bounded SQL snapshot, constrained by caller source permissions and historical validity. Selection uses declared lexical topic matching rather than an unrestricted graph walk. The snapshot cap is 10,000 chunks and 8,000,000 source-text characters; overflow fails without selecting an incomplete scan.

Section organization is deterministic and does not prove a source's architecture. Design sections such as Requirements, Architecture, Interfaces and Validation remain explicitly missing when no selected source supports them. The workflow does not invent decisions or fill gaps merely to produce a polished document.

New wording with independently checked meaning

The document tone path extends the existing stylistic -> style_verify output graph with reviewed technical predicate constructions. The lexicon now contains twelve constructions: ten for the original five factual relations and two for technical document predicates. Eligibility and relationship exclusions precede the semantic/intensity/tone/genericness ranking. Ranking scores are not confidence that a source is true.

The generator can combine complete predicates about one subject with additive conjunctions, use limited friendly contractions and use an explicitly licensed same-subject pronoun. An independent inverse grammar recovers the original predicates and verifies complete claim coverage and source fingerprints. Numbers, negatives and qualifiers are retained. Unsupported or complex records remain attributed source quotations, rather than being discarded or simplified.

For example, the fictional source statements “Helios stores encrypted backups.” and “Helios uses PostgreSQL for metadata.” produce the new sentence:

Helios stores encrypted backups and uses PostgreSQL for metadata.

The prompt is:

Write a detailed article about Helios in a friendly tone.

Neither source contains the requested friendly style. The recorded twelve-fact article/report retained every claim, including the negative failover statement. This validates bounded construction behavior on those fixtures, not arbitrary language generation or independent factual accuracy.

Output and integration contract

For ordinary documents, reply.text can publish verified derived prose with literal fallbacks. document.sections[].prose holds generated sentences and their source IDs. document.sections[].quotes and answer_evidence retain the original source text, offsets and chunk SHA-256 values. rendered_response.canonical_text preserves the quotation-only view. stylistic records actual node execution, status, selected construction, score components, tone alignment and verification. The older single-fact path still publishes a companion without replacing its canonical reply.

An HTTP message can contain the same explicit tone instruction; no new HTTP style field is introduced. Strict reports remain quotation-only even when tone is requested. No generated wording inherits a clinical or world-truth audit.

Length, layouts and missing coverage

Standard, detailed and brief documents allow eight, sixteen and three atomic source units, capped at twenty for explicit numeric requests. String tone profiles use the document budget; explicit StyleOptions limits are honored without deleting claims. Exact word/sentence counts are not guaranteed. Records and necessary qualifiers are never clipped to pad or fit a response. Selected atomic text over 200,000 characters fails closed.

The same document representation renders to Markdown/HTML reports, tables, bullets and numbered lists. Coverage includes missing sections, recognized attribute conflicts, included records and further pages. Continuation preserves page size, section outline and time validity while rechecking current permissions. It is not an immutable signed database snapshot.

Call the document workflow

result = app.ask("Write a detailed article about Helios in a friendly tone.")
print(result["reply"]["text"])
print(result["rendered_response"]["canonical_text"])

Send the same prompt in the message field of POST /v1/ask; do not add an HTTP style field. See the runnable example and captured receipts: https://github.com/insightitsGit/cpullm/tree/75425fc/docs/examples/2026-11-03-prompt-tone

10 Financial component example

The finance component can be called directly without constructing an appliance. Inside an ordinary appliance, the same structured prompt can use app.ask(request, finance=True). A strict appliance does not enable finance specialists for one request; choose the direct component or a separate ordinary appliance for structured checks.

from cpu_llm.finance import validate_message

request = """Decide this LedgerCovenant test.
comparator: lte
threshold: 4.50
numerator: compliance_certificate 9000001
denominator: compliance_certificate 2000000
ratio places: 6
"""
result = validate_message(request)
print(result["text"])
print(result["checks"])

The stored six-place result is 4.500001, which breaches lte 4.500000 under the component's stated rounding policy. Presentation retains enough digits to explain that decision. A requested/default smaller display precision is a minimum, not permission to hide a deciding digit. Decimal strings and exact scaled values avoid accepting floating-point inputs as exact financial amounts. The scaled decision policy itself is bounded; this is not arbitrary-precision legal interpretation or authentication of a compliance certificate.

11 HTTP service and authorization

Upgrade when ordinary HTTP requests disconnect

In 1.11.0, a strict request could succeed while an ordinary client disconnected: SQLite-backed appliance state crossed request threads. Version 1.11.1 handles requests serially on the serving thread and closes response connections so idle keepalives cannot occupy that server. This correction does not increase concurrency. Embedded Entry factories must lazily construct thread-affine appliances on the serving thread, never return an instance constructed on another thread.

The four authenticated POST routes and strict-floor precedence are unchanged. Request tone in the message text, not a style body field. The checked-in OpenAPI 3.1 examples document the contract; there is no runtime Swagger or OpenAPI endpoint. https://github.com/insightitsGit/cpullm/blob/c2de454/docs/openapi.json

The service binds to 127.0.0.1:8765 by default. Prepare a credential file containing SHA-256 digests, canonical tenant IDs and permitted source prefixes. cpu_llm.entry.secret_sha256(secret) computes the digest; do not put the secret itself in that file or a public example. Send the secret using the Bearer header.

cpu-llm-serve --secrets credentials.json --strict-evidence

Use --no-small-talk for evidence-only envelopes. Path ingestion is off unless an ingest root is explicitly configured. The four HTTP routes use POST:

POST /v1/ask HTTP/1.1
Authorization: Bearer YOUR_LOCAL_SECRET
Content-Type: application/json
X-CPU-LLM-Evidence-Mode: strict

{"message":"What is the material of Example Device?"}

HTTP ask accepts discover, imagine, deep, math, finance, as_of, session_id, strict_evidence and small_talk. It does not expose every Python argument. Caller identity/source scope comes from the authenticated credential, not a caller object supplied in the request body. Strict header/body/operator activation uses enable-wins precedence; an operator small-talk disable cannot be re-enabled by a request. Invalid boolean or strict-header values are rejected.

Entry wraps reads and mutations with credential/source checks and restricts server-path ingestion to its resolved root. Direct Appliance.ingest and delete_source methods are trusted backend APIs, not authorization endpoints. Do not expose them directly to untrusted clients. The stdlib server is not a full production gateway: deploy TLS, access policy, request limits, logging and operational controls appropriate to the application.

12 Python API reference

The historical extracted signatures and node inventory in cpu-llm-1.10.0-api-reference.json describe an earlier release. The concise reference below is an integration overview, not a complete 1.13.1 signature listing. For current constructors, external fallback configuration and service controls, use https://github.com/insightitsGit/cpullm/blob/main/docs/library-consumer-guide.md. Internal node functions are not standalone public APIs.

Appliance construction: checkpoint=None and keyword-only dsn=None, child_safety=None, namespace=None, on_escalate=None, reference_backend=None, prompt_backend=None, resonance_tags=False, strict_evidence=False, small_talk=True. The reference backend defaults to disabled. Prompt auto uses available optional parser assets or a reported rules fallback; rules avoids the parser and spacy requires its assets. Resonance tags are off by default.

Ask options: message, optional propositions, then keyword-only discover, imagine, deep, math, finance, payment, authority, objective, hypothesis, causal_graph, realization, account, grade, child_safety, session_id, caller, as_of, style, strict_evidence, small_talk. Boolean agent switches default false. Most optional typed inputs default null. realization defaults to deterministic, small_talk to the appliance policy through null, and strict_evidence to false subject to the constructor floor. Payment requires both proposal and authority snapshot. Treat advanced typed inputs according to their component contracts; their mere presence does not establish independent factual verification. Accepted realization labels are deterministic, evidence_neural and model01; these are not three trained decoder checkpoints. In the current single-turn implementation the request-level grade and child_safety arguments are discarded. Their presence in the signature must not be marketed as effective per-request safety enforcement or clinical policy.

Data and lifecycle: ingest(source) returns an ingestion receipt; index_chunks stores caller-split paragraphs; catalog_chunks additionally registers repeatable catalog/proposition information; upsert(id, text) is a single-chunk helper. correct accepts a document ID, exact old/new sentence, actor, timestamp and optional caller. delete_source(source) removes the named source. clear_session_state() clears conversation/planning state; close() releases workers/resources. Use Entry for untrusted mutations.

Concurrent requests: ask_concurrent adds request identity/caller and an optional Thinker factory to a seat-managed ask. It is not automatic deployment of a distributed cluster. A returned other_server/error outcome is not an answer. Validate the chosen worker/storage layout under actual workload.

Installed commands: cpu-llm-demo, cpu-llm-conversation-candidates, cpu-llm-serve, and cpu-llm-ingest. The ingestion command operates on bundled corpora; use the Python ingestion API for custom documents. Help/invalid flags exit before model/database construction. External conversation candidate exports remain a review queue, not auto-imported runtime answers or new medical facts.

13 Historical evidence and reproducibility

The published 1.11.1 wheel and source archive matched the exact tested artifact hashes. The source suite recorded 905 passed, 56 skipped, three existing expected failures and six existing NumPy warnings. The service, schema, thread and keepalive checks recorded 19 passes. With a lazy factory the installed patch passed the strict request and all three ordinary clients; the published 1.11.0 reproduced the failure. The packaged healthcare demo passed 12/12 authored checks using cached offline assets and isolated native PostgreSQL 18 with pgvector. Compose configuration validated; Docker startup was not verified because the host's Docker Desktop failed before Engine startup. These results do not measure clinical accuracy or throughput.

Patch evidence and artifact digests: https://github.com/insightitsGit/cpullm/blob/c2de454/docs/releases/1.11.1-build-validation.md https://github.com/insightitsGit/cpullm/blob/c2de454/docs/releases/1.11.1-artifacts.json https://github.com/insightitsGit/cpullm/blob/c2de454/docs/reviews/2026-11-03-public-artifact-audit/REPORT.md

Earlier 1.11.0 feature validation

The published wheel and source archive match the hashes of the tested artifacts. A fresh Windows Python 3.12.10 environment installed the wheel without system site packages, passed dependency checks and all four CLI help checks. Real database queries verified friendly generation, strict bypass, HTML/lowercase topic handling, literal conditional fallback and caller-source exclusions. Packaged healthcare and conversation demos each passed 12/12 authored software checks. Sixty-four targeted source regressions accompanied release preparation.

These checks do not establish clinical safety, authoritative source truth or superiority to a hosted model. Earlier benchmark counts belong to their recorded revisions and fixture sets. Typed object-category queries, general aliases/joins, arbitrary prose conflict detection, general expressive writing and novel design proposals remain explicit limitations.

Release and artifact digests: https://github.com/insightitsGit/cpullm/blob/92002fd/docs/releases/1.11.0-publication.json

Historical evidence from earlier revisions

The published 1.10.0 release passed strict distribution metadata checks. Archive verification checked 125 runtime/resource files, including the trained projection, data, demo resources and installed commands. A clean base installation with no system site packages passed dependency checks and both installed demos: healthcare 12/12 and conversation 12/12 authored checks. The final source test suite passed 897 tests, with 2 skipped and 3 pre-existing expected failures. The full suite and the clean-install demos are different validation scopes.

Historical authored comparisons provide additional engineering examples, not clinical or hosted-model superiority results. The 32-case medical run at revision 26a5215 reported full-contract passes of medication: ordinary 9/16, strict 16/16, simple literal/calculator 9/16; healthcare records: ordinary 15/16, strict 16/16, baseline 10/16. Correct visible arithmetic with a held final status was counted as a delivery-contract failure, not fabricated number drift. Some tasks require correct refusals rather than answers. The ordinary, strict and baseline paths are library/components; no generative LLM arm was installed or run in that comparison.

A separate 42-case authored strict evaluation reported 42/42 versus 25/42 for its limited literal/calculator baseline. The unchanged 24-case domain replay reported 24/24 after routing/precision/context fixes. These runs used earlier recorded revisions and different cases/scorers; they must not be added together or presented as a single 1.10.0 clinical accuracy rate. The data, frozen receipts, raw responses, corrected scorer history and hashes are retained in Git.

The 1.10.0 published upload artifacts were verified against the tested SHA-256 hashes. Neither distribution validation nor a perfect authored fixture score proves clinical safety, arbitrary question coverage, data quality, security certification, universal hallucination prevention or competitive LLM accuracy. No independent clinical gold/sign-off was supplied. No energy, carbon, latency or cost advantage over a hosted model was measured here.

14 Deployment checklist and next steps

Start with the installed fictional demos and a small representative corpus. Keep source normalization, temporal validity, caller scope and the selected response mode explicit. Retain accepted evidence and refusal reasons. Define what the application may do with quotations, calculations, partial results and policy replies before enabling autonomous actions.

For healthcare, establish authoritative source/version policy, clinical intended use, independent expert gold/review and separately validated treatment/diagnostic rules if those decisions are intended. For finance, validate source authority, numeric policy, precision, input completeness and action approval. The library alone does not provide those organizational or professional controls.

Use cached assets and restricted egress when offline operation is required. Benchmark startup, ingestion, memory and concurrency on the actual hardware; do not infer a performance SLA from a small demo. Re-run supported and refusal cases after changing parser assets, schemas, rules, source readers or dependency versions. Keep unsupported forms visible instead of silently widening claims.

The next step for a developer is concrete: install the public 1.13.1 package, run the two demos, inspect their JSON receipts, ingest a representative document and verify the request/result contract against the application's requirements.

References and implementation authority

  1. Published package: https://pypi.org/project/cpu-llm/1.13.1/
  2. Repository and license: https://github.com/insightitsGit/cpullm
  3. Published release and build source: https://github.com/insightitsGit/cpullm/releases/tag/pypi-v1.13.1
  4. Release verification: https://github.com/insightitsGit/cpullm/blob/40ead1e/docs/releases/1.10.0-build-validation.md
  5. Strict contract: https://github.com/insightitsGit/cpullm/blob/0102bc0/docs/strict-evidence-spec.md
  6. Conversation contract: https://github.com/insightitsGit/cpullm/blob/0102bc0/docs/conversation-spec.md
  7. Stylistic specification: https://github.com/insightitsGit/cpullm/blob/75425fc/docs/stylistic-generation-spec.md
  8. Flag registry: https://github.com/insightitsGit/cpullm/blob/0102bc0/src/cpu_llm/flag_contract.py
  9. Python pipeline: https://github.com/insightitsGit/cpullm/blob/0102bc0/src/cpu_llm/pipeline.py
  10. HTTP service: https://github.com/insightitsGit/cpullm/blob/0102bc0/src/cpu_llm/serve.py
  11. Healthcare demo and actual replies: https://github.com/insightitsGit/cpullm/tree/0102bc0/examples/healthcare
  12. Medical comparison: https://github.com/insightitsGit/cpullm/blob/0102bc0/docs/benchmarks/2026-11-02-medical-local/REPORT.md
  13. Strict evidence acceptance: https://github.com/insightitsGit/cpullm/blob/0102bc0/docs/benchmarks/2026-11-02-evidence-v2/REPORT.md
  14. Domain replay: https://github.com/insightitsGit/cpullm/blob/0102bc0/docs/benchmarks/2026-11-02-domain-replay-v2/REPORT.md
  15. Healthcare acceptance gate: https://github.com/insightitsGit/cpullm/blob/0102bc0/docs/healthcare-evidence-acceptance.md

This is an implementation whitepaper with AI-assisted drafting and mechanical API/artifact checks. It is not an independent peer review. Example labels, records and dialogue facts are fictional unless explicitly identified otherwise.

Earlier editions: 1.13.1 pre-publication evaluation PDF · cpu-llm 1.11.2 PDF · cpu-llm 1.11.1 PDF · cpu-llm 1.11.0 PDF · November 2, 2026 · cpu-llm 1.10.0 PDF.