Written before go-live, computed after
A JetStore installation has two parts. The platform is JetStore's software: a data pipeline engine, a rules engine, a database and the services around them. The workspace is what makes an installation yours. Where AI fits depends on the moment you ask about — while your workspace is being written, or once it runs.
-
Your workspace
What makes it yoursA set of declarative files — data model, rules, reference tables, pipelines, process configuration and reports — compiled and versioned. Each file states what should be true or what should happen, and the platform does the rest. Your data is defined once, and the platform's tables and rules are built from that one definition.
-
Written at installation
Before go-liveArtiSoft uses a frontier model to write the bulk of your rules, pipelines and templates — the work that has always made a rules engine expensive to adopt. Every rule file, data model and pipeline configuration it writes goes through the same compiler and validator a person's work would, and nothing is deployed until your people have reviewed and approved it. The model works on your configuration and does not need access to member data.
-
Run by the platform
After go-liveOnce your workspace is approved, the frontier model's job is done. Rules and pipelines compute: files are parsed, mapped and cleansed by pipeline steps, and rules derive each member's facts. Where a step needs a model, it is one you host, and nothing is sent to an outside AI provider. Some products use no model at run time at all — AgentBrief builds each member's briefing with rules and a fixed template.
A frontier model writes the bulk of the workspace before go-live. After go-live the platform runs it, and a model you host is scoped to the steps that need one. The question stops being who here can write this rule and becomes is this the rule we want.
Two engines, and a clear line between them
An agentic system over data operations needs five layers: observation, reasoning, supervision, action, audit. On JetStore, four of the five already map to existing features of JetStore — the deterministic layers are the platform. The reasoning layer is what the agentic work adds, and the line between it and everything else is the design.
-
Observation
DeterministicThe execution record is the platform's own: run status, per-node execution detail, process errors, the input and session registries. It is a near-complete record of what a pipeline did and a partial record of what went wrong with it — and what gets built on top is designed against that difference rather than around it.
-
Reasoning
CognitiveAn inference server on GPU, and a pipeline operator that calls it once per record. Around them sits the runtime this work was built for: the tool registry, the domain-model contracts, the tier enforcement point, the evaluation harness, and a propose–verify–repair loop. No agentic framework is a dependency of any of it.
-
Supervision
SharedUsers, roles and per-capability checks are in the API server today, and agent authority is designed to ride on that same capability model: an agent identity is a user with a capability set, so what it cannot do is a property of the access model rather than of its instructions. The agent-facing half — where an autonomous step is graded and approved — is what the agentic work adds.
-
Action
DeterministicCompute Pipes DAG execution, workspace compilation, orchestration. A step with one correct answer is computed here rather than inferred, at the volume the data actually arrives in. Nothing in this layer is inferred.
-
Audit
SharedA dedicated audit logger whose call sites write before the access check and before the action, onto a log stream that cannot be edited after the fact. Making that record durable across a crash, outcome-carrying, and queryable by the product itself.
Nothing in that list asks a model to do a compute platform's job. The expensive, error-prone part of working with claims data is not the prose — it is assembling a correct, deduplicated, coded, adherence-computed longitudinal view out of raw feeds. Rules do that, deterministically. What is left for the model is rendering an input that is already correct, or reasoning where no deterministic answer exists.
A frontier model earns its keep at a different point: before go-live, writing the bulk of your workspace, as how an installation is built describes above. It is not in the pipeline at run time.
The model is an operator in the pipeline
Inference is not a service the pipeline calls out to and hopes for. It is a step in the DAG, with the same configuration surface, error handling and cost controls as every other step — and it is built and tested rather than planned.
-
Per-record inference, with the plumbing already around it
Prompt templates with column and whole-record placeholders, compiled at build time. JSON-schema structured output. Dot-path mapping from the response back into the record, with typed casting. A worker pool, retry with backoff, a dedicated error channel — and a cap on how many records are sent to the model, so the cost of a run is bounded; records past the cap pass through without the model's answer.
-
One domain model, declared once
The domain model is declared once and compiled into the database tables, the rule engine's types and the platform's registries. For the agentic layer, each entity is written once and six artifacts are generated from it — the rule-language class, a JSON Schema, a database table, data-classification markers, tool signatures and a metadata file — with a check that fails the build if they disagree.
-
Constrained on the way out, checked on the way in
A model step's answer is constrained to a declared shape, and that schema is written with the pipeline. Every value that comes back is checked and converted to the type its column expects. A record that fails is reported on an error channel, and the pipeline's author decides whether it is dropped, stops the run, or continues without the model's answer.
-
A deterministic renderer, where a template is the better answer
Sometimes the finding is that inference is not the right renderer at all. A configuration-driven render step applies a template to a record inside the running pipeline, and every failure that engine admits is a build failure rather than a run one. That is a finding the platform can act on rather than argue with, and it is the finding behind AgentBrief.
The compiler is the reviewer
Almost nobody building an agentic product has a free, deterministic, high-signal verifier for the artifacts their agent is supposed to author. A rule compiler and a pipeline-configuration validator are exactly that. Designing the whole model strategy around them is the difference between a demonstration and something you can put in front of an engineer.
-
An output contract
Every artifact an agent authors — a pipeline configuration, a domain model, a rule file — goes through a compiler that decides whether it is well formed. Quality is measurable from the first day, with no golden-case library, no historical incident data and no evaluation function to invent first.
-
An inference-time repair signal
Generate, compile, feed the compiler's own error text back as a structured repair prompt, retry within a bounded iteration count. The messages work as repair prompts because they were written for people: name a column a template does not have, and the build error lists the columns it does.
-
Verification runs in parallel, so generation can too
Both rule engines validate concurrently with session isolation, so a batch of candidates can be checked at once. Sampling several and keeping the ones that compile is usually a better use of a fixed token budget than several repair turns on a single candidate, because the failures are independent draws rather than one fixable mistake.
-
Authoring is machine-verified before a human sees it
Rules and pipeline configurations are written with a copilot whose output passes the compiler first, so a reviewer spends their attention on whether the logic is right rather than on whether it parses. Human review is structural here — a property of the workflow, not a control designed on top of it.
-
One tool catalog, two consumers
The tool boundary is MCP — a wire protocol under the Linux Foundation's Agentic AI Foundation with a v1 compatibility guarantee on its Go SDK, adopted as a protocol rather than as a framework in the runtime. One registry of named tools, typed against domain entities, serves a frontier model while the work is being designed and the in-house model when it runs.
Graded against the code on 2026-09-11, two of the verifier's three roles are built: the output contract and the repair signal. The third — the same compiler used as a training signal for the in-house model — is a dependency away rather than a decision away, and we would rather name it than count it.
Inference you host, and a seam where you need something else
ArtiSoft recommends JetStore Agentic AI: the reasoning layer runs on inference you host, so no external LLM provider is required and PHI never leaves your VPC.
Where a client's requirements call for a different or external model, the inference layer sits behind a backend interface, so the model is a per-agent configuration choice rather than a rebuild.
-
Vendor neutrality is the product, not a setting
No external LLM provider. PHI never leaves your VPC. That is most of the answer to a security review, and it is the reason the reasoning layer was built to run on inference you host — a framework from a large vendor sitting in the runtime is an answer you have to give in every review, for a capability you could have written yourself.
-
A frontier model teaches; your inference serves
The frontier model's place here is upstream — designing the rules, the prompts, the templates and the golden cases, where its output is reviewed before it runs rather than after. Because the catalog is exposed over MCP it can do that work against the real tools, and the artifacts transfer to the local model without a rewrite.
-
The backend is a seam, and the seam is shipped
The shared inference plumbing — worker pool, retry, error channel, response mapping — was extracted behind a common backend interface, so a serving stack is a configuration choice at one boundary rather than a change threaded through the pipeline. Because agents run as pipeline steps, two branches can run over the same data and be compared as a measurement instead of argued about.
-
Scoped, and explicit about the scope
A self-hosted small model will not match frontier reasoning on open-ended root-cause analysis, and this platform does not claim that it does. The design scopes the local model to the tasks where a verifier exists, and is explicit about which tasks stay with a person. That is a narrower promise than parity and a much more defensible one.
What ships is the interface. Which model, which serving stack, and which steps stay human are scoping decisions for your deployment — we would rather work those out against your data and your review process than put a checkmark beside them here.
It runs in your environment, inside the scope you already maintain
JetStore deploys into your own cloud account. Data under your control stays there, and no protected health information reaches ArtiSoft — which is what makes the compliance conversation short.
-
Your compliance scope, not a second one
Because JetStore runs inside your environment, it operates within the controls and the audit scope you already maintain. We support customers who maintain HITRUST CSF certification, and JetStore runs inside that scope like the rest of their stack.
-
ArtiSoft holds no HITRUST certification, and does not need one
Certification covers an environment that handles the data. ArtiSoft does not handle yours: no PHI is transmitted to us, so there is no ArtiSoft-side scope for a certification to cover. Any vendor telling you otherwise is describing a different architecture.
-
No external model provider in the path
The reasoning layer runs on inference you host. Nothing in a run is sent to a third-party model API, so there is no processor to add to a data-flow diagram and no egress to justify.
-
Access is enforced by capability, per action
Users, roles and per-capability checks are in the API server today, and agent authority is designed to ride on that same capability model rather than on a parallel one.
This describes where the software runs and what it does not receive. It is not legal advice, and your own compliance team owns the conclusion for your deployment.