Models & post-training

Why post-training is part of the product

Prompting and RAG alone rarely produce production-grade agents for regulated or ERP-heavy work. Those systems must call tools in the right order, verify external claims before accepting “success,” and stay efficient enough to run on appliance GPUs with real concurrency.

Ivertiq therefore treats post-training as a first-class layer of the Full-Stack AI Harness — alongside orchestration, validation, and vertical apps — not as a one-off science project.

Post-training objective: system capability

Post-training objectives are set holistically. The goal is not a better chatbot or a higher general benchmark; it is a model that helps the agentic layer complete system objectives under customer SOPs — on sovereign hardware, with provenance and human gates.

That means we train for the capabilities the workflow needs: domain judgment and the thinking and tool-use patterns that let agents plan, call skills, and verify outcomes. Domain knowledge without tool discipline fails in production; tool calling without vertical judgment fails the same way.

How those objectives are weighted is vertical- and workflow-specific. The mix is derived from what the Full-Stack system must reliably do — not from maximizing language-model capabilities in isolation.

What “post-trained best-fit” delivers

Best-fit means the model can be licensed for on-prem use, right-sized to the appliance memory envelope, post-trained for tool use and task stability, and swapped when a better fit appears — without forcing core data onto a public LLM API. It is not “best-in-class” on a general bench, and not the largest model that will load. In practice that delivers two coupled gains:

• More vertically specialized knowledge and judgment — ERP / SOP language, procedure-aware paths, bilingual operational phrasing the agent needs to choose correctly.
• Stronger agentic performance — better tool calling, anti–false-verify discipline, and efficient chain-of-thought so the agentic layer plans, acts, and verifies under human gates — often with less thinking overhead on domain tasks, not open-ended “think longer.”

Quality and latency tiers (for example open Qwen-class dense orchestrators vs MoE latency-oriented lines) let the Harness route high-verification work and high-frequency work differently — same post-training objective, different cost/latency envelope.

How we score models

We evaluate the system, not a chatbot scorecard: tool-call rate, checklist / Validation Pack pass, HITL correction rate, and tokens or latency per Case. The ERP figures later on this page are an illustrative internal program — not a public leaderboard claim, and not a promise that every customer will see the same lift.

Train privately. Serve on-prem.

Post-training needs more GPU than a single office appliance. Production inference needs the weights and the records in a room the customer can point to. Ivertiq splits those environments on purpose.

Adaptation runs on Ivertiq-operated or customer-contracted private cloud — not public LLM APIs for core regulated corpora. Production serving runs on-prem Node / Station or a siloed private cloud — same Harness, same HITL gates. See Security and Deployment.

Model progress is a tailwind

Frontier and near-frontier model advances — including rapid open releases — are a tailwind, not a threat. Ivertiq does not bet the product on one proprietary API: we assemble, vertically fine-tune, and optimize systems holistically for regulated verticals. New breakthroughs expand the toolkit. Better foundational models give richer dimensions for targeted, data-curated post-training toward vertical specialization. The Harness stays; the local engine can be replaced.

Fast adaptation is the operating model: constantly bringing in state-of-the-art models and methods without waiting for a long platform rewrite — then deploying them under sovereignty and human-in-the-loop controls. Measured gains remain workload- and Validation Pack–specific; we do not claim that any single public release automatically delivers a fixed quantitative lift for every customer.

Enterprises are prioritizing model sovereignty for two reinforcing reasons: (1) the capability gap between frontier open and closed models has narrowed considerably, and (2) access to frontier closed models can still be constrained by policy or jurisdiction. That is why we localize, vertically post-train, and inference-optimize open / open-weight models — so control of the model and the inference stack is practical at enterprise scale, not only preferable in principle.