Models propose, code decides: verified, traceable and controlled analytics for regulated work

1Introduction

Analysts in regulated organizations spend much of their time turning tables and documents into reports: a quality report for a hospital board, a variance pack for a finance committee, an assessment for a policy maker. Language models can draft such reports in minutes. In our experience, four failure modes keep them out of work that must stand up to an auditor, a regulator or a court.

1. Unverified numbers. A model can write a figure that no query produced, attach it to the wrong period, or round it one way in the text and another in the chart. Office files add drift of their own: an uncached formula or a template cell can show a number the analysis never computed.
2. Unreliable queries. Real schemas carry join traps, nulls, ties and dialect differences. Text-to-SQL benchmarks show a wide gap between clean schemas and realistic ones [16, 17].
3. Facts mixed with judgments. Models blend observed facts, assumptions, estimates and conclusions, and use probability words such as “likely” with no stated scale. Analytic standards require these to be kept apart and expressed on a declared scale [1, 2, 3].
4. Governance that stops at the database. Health, criminal-justice and national-security rules apply to every copy of the data, not only to the table it came from [9, 10, 11]. They fail silently when the data reaches a prompt, a log, a trace or an exported file that no control sees.

What these failures share is that they are invisible in the finished artefact. A wrong number looks like a right one. An assumption phrased as a fact reads like a fact. A file sent to the wrong person leaves no trace in the file. The design described here aims to make each failure either impossible by construction or visible and recorded.

Two properties

We make the goal precise with two definitions.

Contributions

• An architecture in which every printed number is bound, recomputed by an independent path and read back from each rendered file, and every report element is traced (Sections 3, 4 and 7).
• A treatment of statistical claims in which words such as “significant”, “trend” and “outlier” must be earned by a test, and small counts are suppressed and then audited against an attacker (Section 5).
• A way to compute analytic standards, including claim types, likelihood, confidence, alternatives and calibration, from signed rule packs rather than prompts (Section 6).
• A model of ingest trust and dissemination in which the provider’s conditions travel with the data and each act of sharing is decided once and recorded in a signed chain (Sections 8 and 9).
• A distribution model for sector rules as signed, versioned content with locks that only tighten (Section 10), and an account of how all of this is tested (Section 12).

2Design principles

Two kinds of system exist today. Agents that let a model write SQL or code and print the result are flexible, but errors compound across steps and provenance is lost. Business intelligence platforms enforce semantic models and access rules, but leave planning, reconciliation with documents and the narrative to people. DataLogiX sits between them. Seven principles shape it, and each is enforced by tests, linters or the run-time state machine rather than by convention.

1. Models propose, code decides. Every model answer must parse into a typed contract and pass a code check before it has any effect.
2. Every number is verified. A number reaches a report only as a registered value with lineage. It is computed by a verified function, recomputed by an independent path, checked by rules and read back from every file.
3. Every element is traceable. Each sentence, cell, chart point, key figure, marking and style choice has one record in a signed trace, located in every format.
4. Dissemination is decided, not assumed. Every route that returns content declares which act it performs and passes one gate that applies the organization’s policy and writes a signed record.
5. Headless. The web application has no private access. It calls the same public API as the SDKs and the server that AI assistants use, so every control applies to every client.
6. Configuration is signed content. Markings, analytic standards, records rules, access rules, review chains, products and domain rules live in expert packs, resolved by a kernel that knows no domain.
7. Isolation by default, failing closed. Each organization has its own cloud project, keys and signed database scope. A missing label, policy, signature or check refuses the action.

3From question to report

Every analysis runs as one durable workflow with a fixed sequence of stages. Each stage is a typed activity that can be tested offline against recorded model answers, and the workflow code is deterministic, so a run can be replayed exactly. A change to the workflow ships under a version marker, so runs already in flight keep the behavior they started with.

Table 1. The stages of an analysis.

Planning on metadata

Intake and reconnaissance see the shape of the data, never its contents: table and column names, types, row counts, coverage dates, published metric definitions and, where needed, a few masked sample values. The planner proposes a graph of steps in a typed language, and the critique comes from a model of a different family so that one model’s blind spots are less likely to be repeated. Validation then checks the plan against the catalog and the organization’s grants before anything runs. Where a person must approve, the approval names a hash of the plan, which closes a subtle gap: without it, a plan edited between being read and being approved could be approved unseen.

Queries in the source’s own dialect

Metrics defined once in a semantic layer are compiled directly into each database’s dialect. Free-form SQL is written natively in the source’s dialect and never translated at run time, because translated SQL proved fragile across database versions. Every statement passes a guard before it runs: it must be a single read-only statement over allowlisted tables and columns, it receives a row limit, and it is validated on the target database first.

For a free-form question, three candidate queries are written independently and compared by their results, not by their text. When candidates disagree, we do not ask a model which one is right. Instead, code searches for distinguishing data: tiny tables built from the queries’ own constants together with nulls, zeros and boundary dates, on which the candidates produce different answers. A critic then sees only the question, those rows and each candidate’s output, never the organization’s data. It may choose a reading, which is then printed with a caveat, or decline, in which case the user is asked. The approach turns an argument about code into an observable difference in behavior.

The writer never sees the data

The model that drafts the report receives value identities, labels, units and dataset summaries. Code rejects any digit or spelled-out count in its draft. A number appears in the text only as a binding that code resolves to a registered value, so the writer can arrange numbers but cannot invent, round or misplace one.

Model-written code

Some exploratory work is best done in code a model writes. Such code runs in a job with no network, under a static policy and an operating-system filter, and its results are registered as exploratory. An exploratory value can inform a person but can never be stated as a figure in a released report.

4Verification: every number

Numbers in generated reports go wrong in six ways, and each has its own check (Table 2). All of the checks run in code, in a fixed order, before any file is released (Figure 2).

Table 2. Six ways a reported number fails, and the check for each.

Functions with two implementations

Every computed number comes from one entry point into a library of verified functions. Each function declares its formula, citation, preconditions, units and exactness, and carries a primary and an independent secondary implementation. A call checks the preconditions and refuses rather than returning a non-number; checks units and currencies against a shared registry; records a hash of the function’s source with the result; and, in verification, runs the secondary implementation and refuses a divergence beyond tolerance.

Money never uses binary floating point. Amounts are exact decimals at the currency’s minor unit, allocation distributes remainders without losing a cent, and a currency conversion needs a declared rate, date and source. A conversion that is neither identical, declared nor covered by a dated rate is reported as a slip, never done silently.

Two further layers sit behind the library. The statistics are tested against the certified values of NIST’s Statistical Reference Datasets [13], including the ill-conditioned cases, where inputs are scaled and centered exactly before squaring. Key functions also have reference implementations written in the Lean 4 theorem prover [26], run against the product on large randomized samples every night with no disagreement allowed, and rule catalogs are checked for contradictions with SMT solvers [27, 28]. A person reviews every theorem statement, because a proof is only as good as the statement it proves.

The value registry

After the tools run, code registers every number the report may show. Values are named from their step and output, never from the data, so no row value enters an identifier. A metric query registers its cells and, for additive measures, its totals; a SQL step registers one-row aggregates, totals of columns shown to be additive from the query’s syntax tree, and keyed per-row values; a fact lookup registers one cited number per row; statistics and forecasts register their outputs with interval bounds. Code refuses to register a column that is not an aggregate, an aggregate over an identifier such as a record number, a value with incomplete lineage, a truncated result or a non-finite one. The registry is append-only and encrypted per organization.

Reading text as a reader sees it

Rules are only as good as their view of the text. Before any rule runs, the verifier normalizes the text to what a person would see: it folds compatibility forms such as full-width digits, treats invisible characters as word breaks, and maps look-alike letters from other scripts to Latin using the Unicode confusables data [14]. A word that mixes scripts is refused, so a digit disguised as a letter from another alphabet cannot pass.

Four families of rules then apply. Bindings must resolve to registered values, and nothing numeric may touch a binding, such as a scale word or a second percent sign. Digits may not remain once bindings and the pack’s allowed tokens (a quarter or a fiscal year) are removed, apart from calendar years inside the run’s date scope. Number words above two, fractions, ratios and magnitudes are refused in prose. Charts and caveats need a unit and a source note, forecasts need an uncertainty band, and required caveats must appear word for word.

Is each sentence supported?

Rules catch numbers that should not be there. They cannot catch a well-formed sentence that its evidence does not support, such as a cause the data does not measure. For that, a model of a different family from the writer reads each section. It sees the heading, the numbered sentences and summaries of the bound values (label, unit, displayed value, interval), never rows or queries.

The model does not give a verdict. It decomposes each sentence into its parts, namely a level, a change, a cause, a comparison or a superlative, and states for each part whether the cited evidence states it, contradicts it or is silent. Code then decides. A contradicted part, or a missing cause or superlative, makes the sentence unsupported and vetoes its section. A change is supported only if a bound value actually measures a change: a single period’s level never proves that something rose or fell. Any other missing part makes the sentence unclear, which flags it. The sentence’s verdict is the stricter of code’s and the model’s, so a model can veto a sentence but never approve one that code refused. Asking for parts rather than a verdict made the check markedly more sensitive in our measurements without adding false alarms. A section still vetoed after a bounded number of rewrites goes to a person, who either accepts the quoted sentences on the record or stops the run.

A second path for every value

At verification, every bound value and every published table cell is computed a second, independent way (Table 3). The aim is not to repeat the same computation but to reach the same number by a route that does not share its likely failure.

Table 3. Independent second paths by kind of step.

When a warehouse returns a binary floating-point sum, exact agreement is the wrong test. The second path also fetches the row count and the sum of absolute values and applies the classical forward-error bound for recursive summation [15]:

If the bound itself exceeds half of the currency’s minor unit, the value cannot be confirmed and is treated as having no second path. Exact decimal columns must match exactly. A mismatch fails the run.

Honest value states

A value is in one of four states in a batch report: computed, a number; insufficient, no number, with how much data was found and how much was needed; conflicting, no number, with every reading and its source; or degraded, a number whose check could not run, held until a person overrides it by name. Every renderer prints a state through one function, so the workbook, the deck, the document and the web page say the same thing.

When several readings of one value exist, code applies a fixed order that gives the same answer whatever order the readings arrive in. It drops readings whose checks failed and reports their sender withdrew; counts copies of one origin once; keeps readings with different scopes apart; prefers the newest reading of an effective-dated value; and then applies the organization’s own precedence rules for that field, metric or kind of entity. If the runner-up still differs materially, the value is conflicting and a person chooses. Values are never averaged, and an overruled reading is kept as a note rather than dropped.

Reading every file back

A check of the report’s specification proves nothing about the files a reader opens. After rendering, code opens each file, recovers every shown value and compares it with the registry: it must match its formatted string and agree within half a unit of its displayed precision. No placeholder may survive, no chart may compute a number in the reader’s browser, bar and column axes must start at zero, and a lint refuses any digit in an Office file outside its data cells and evidence. A file that cannot be read fails closed.

5Statistics that earn their words

Words such as “significant”, “trend” and “outlier” carry statistical meaning that readers rely on. The writer may use them only when a test, a regression or a control-chart rule supports them.

Choosing the test and correcting for many

Code picks each comparison’s test from the data’s measured properties, checking normality and equal variance and moving to a non-parametric test, or to an exact test for small tables, when the data call for it. The chosen and the rejected tests are both recorded. Across all comparisons in a report, p-values are adjusted together by Holm’s method [18], or by the Benjamini–Hochberg procedure [19] where the organization’s pack says so, because a report that makes twenty comparisons will otherwise find something “significant” by chance.

Control charts in exact arithmetic

Run charts, XmR charts, p-charts and u-charts implement their run rules as pack data. Every comparison against a control limit is made in exact rational arithmetic, and floating point is used only for drawing, so a point never moves across a limit because of rounding.

Small counts and the attacker’s audit

Count tables about people pass three steps before publication. Primary suppression hides each cell that fails the pack’s rule, for example a rule against publishing counts of one to ten. Complementary suppression hides further cells so that the hidden ones cannot be recovered from the margins, using an elimination method from official statistics [20] implemented in exact integer arithmetic. An audit then asks a solver for the tightest bounds an attacker could place on every hidden cell, using linear and integer programming. Integer and non-negativity constraints can pin a cell that linear algebra alone would leave free, so each bound is certified by an integer completion of the table. A cell recovered exactly or bounded too narrowly triggers more suppression and a new audit; an audit that cannot finish publishes nothing [21]. Readers see one public reason for every hidden cell, and which rule hid it stays internal.

Reliability of published rates

A rate is published only if it meets the pack’s reliability rules, such as minimum numbers of events and a maximum relative width of its confidence interval [22]. To judge a rate, code needs its numerator and denominator, so they are carried as companion columns of the same guarded query and removed before results are compared. Survey designs declared in the metric definitions contribute strata, clusters and weights. An unreliable rate is flagged with a caveat or suppressed, according to the pack.

6Analytic standards, computed

Verified numbers do not make a sound argument. A model’s prose can present an assumption as a fact, use probability words inconsistently, confuse how likely an event is with how good the evidence is, ignore competing explanations, and forget what the organization concluded last quarter. Where an organization’s packs include an analytic standard, DataLogiX applies it as rules that code checks. Reference profiles cover ICD 203 and ICD 206 [1, 2], the UK Probability Yardstick [4], the IPCC uncertainty guidance [5], NATO doctrine, STIX [6], GRADE [7], European and US law-enforcement standards, and research-report rules in finance.

Four kinds of claim

In this mode the writer drafts single-sentence claims and code composes them into sections. Each claim is one of four kinds, and each kind has its own obligations (Table 4).

Table 4. Claim kinds and their obligations.

Code types each sentence from the profile’s cue phrases, such as “we assess” for a judgment. A sentence with no cue, or with cues of two kinds, goes to a second reader of a different family, which may object but never approve. Claims form an argument graph: a judgment must rest on claims that reach evidence, and dangling references and cycles are refused.

Likelihood from a number, not a word

The writer never chooses a probability word. It leaves a placeholder, and code fills it from a stored probability. The number comes from a model-based forecast where the judgment states a forecast criterion, from a calibrated score, or from elicitation: two models of different families each give reasons for and against, then a probability, and code pools them in log-odds space. The number is then mapped to the profile’s own term set. Term sets differ in shape (Table 5), and the mapping respects each shape.

Table 5. The shape of different likelihood scales.

By default the range is printed with the word, as in “likely (55–80%)”, so a reader never has to guess what the word means. A profile that prints the word alone must name who waived the range and why.

Confidence computed by code

Confidence is not asked of a model, because a model grading its own evidence tends to grade it well. Code computes it from recorded facts about the judgment and the claims it rests on, through three drivers. Information covers source accuracy, independent corroboration and the currency of the evidence; rigor covers the fit of the method, agreement between independent estimates, the sensitivity of assumptions and how well the evidence discriminates between hypotheses; volatility covers how unstable the underlying series is. A factor with no recorded fact is marked “not assessed” and lowers the ceiling; it never silently raises the score. Caps only ever lower a level: a single source group, for example, caps confidence at moderate. After each key judgment, code writes a note without digits that names what limits the level and the one thing that would raise it most.

Structured techniques

Every listed assumption is tested. A model maps it to the plan’s own parameters, such as a filter value, a grain or a forecast horizon, and the affected steps are re-run into scratch results that can never be cited. If a key value moves beyond the pack’s tolerance, or a judgment’s term or leading hypothesis changes, the assumption is fragile. Key judgments below top confidence receive alternative hypotheses, ranked from pooled probabilities. Challenge techniques run on the profile’s conditions: a devil’s advocate argues against a high-impact judgment and a rebuttal counts only if it addresses the point with real evidence; when two model families disagree widely, the report presents both views rather than an average; and scenarios become indicators that are watched with no model in the loop [3].

Calibration

Judgments with a due date are scored when it passes, with the Brier score [23], the log score and reliability bins:

Once enough judgments have resolved, code fits a recalibration map on log-odds and keeps it only if time-ordered cross-validation shows it lowers the Brier score on later judgments. Reports carry the track record as an appendix whose every number is a registered value, recomputed like any other. Below the minimum history, the appendix says so.

Human accountability

Reviewers act through a log rather than an editor: per claim, they approve, challenge, replace, dissent or waive, each with a reason. Release waits while a challenge is open. A reviewed product is rebuilt with no model call, verified and signed again, and its files name the role of the person who signed and the day.

7Traceability and verifiable files

Each element of a delivered report has a record in its trace: its origin (a query, a document page, a function, a rule or a person), whether it is anchored to that origin, the checks it passed, any review by a person, its marking and a hash of its printed text. The trace is related in spirit to general provenance models [24], but is specialized to the elements of a report and the checks they passed.

Recording origins is not enough; the record must be found in the file a reader opens. Each element is located by its place in each format (cells in Excel, shapes in PowerPoint, bookmarks in Word, named destinations in PDF, paths in the web report) and its printed text is compared with the record. A change outside every known element is caught too. Every Office file and PDF ends with an evidence appendix printed from the trace, linked back to each element. On the web, every number opens its query, rows and data snapshot.

Signatures anyone can check

Signing comes last, after every check. PDFs are signed with PAdES [29] and a trusted timestamp; Excel, PowerPoint and Word files carry a C2PA manifest [25] that also marks them as made with AI assistance. Anyone can check a file without signing in, on the web or offline with a command-line verifier, and receives one of four answers: valid, changed, not signed by us, or unsupported. Every file also states in plain words whether a person reviewed it.

Records that outlive their algorithms

Records of disclosures and report traces must remain verifiable for years, longer than today’s signature algorithms may be trusted. Where the operator turns it on, transmittal records and traces carry a post-quantum ML-DSA signature [30] beside the classical ECDSA signature, so either can be checked, and connections use hybrid classical and ML-KEM key exchange [31] wherever the other side supports it.

8Ingest trust: the provider’s conditions travel with the data

A regulated organization’s data rarely arrives clean, in one place or in one format, and much of it carries its provider’s conditions of use: a sensitivity label, a classification banner, a release list, a statement of how reliable the source is, or a signature that proves who sent it. A system that copies the rows and drops these conditions has broken the provider’s rules before any question is asked. DataLogiX therefore treats ingest as two problems: reach, meaning reading data where it lives in whatever format it takes, and trust, meaning keeping the provider’s constraints attached from the moment the data lands.

Markings on arrival

A file’s marking is read from four places and joined in the organization’s lattice, so the stored label is never lower than any one of them: a floor an administrator declares on the source or dataset; the file’s own metadata, such as sensitivity labels in Office properties or a PDF’s metadata; the text, where banners and portion marks are read with the same grammar the renderer prints; and the parent, so a file unpacked from an archive or an email can only rise above its container. Raising a floor takes effect at once; lowering one waits for a second person. A marking pack can set a ceiling and can require every file to carry a label. Files above the ceiling, unmapped or unlabelled where a label is required are held before any parser reads them, and released only by a person with the authority to do so.

Labels through analysis

Each step of an analysis records the join of the labels of the tables, passages and documents it read, and the run records the join of all its steps. Every later prompt, cached result, export and delivery is checked against that run label by the flow policies, and model policies decide which models may see each kind of data. Usage terms attached to a source, a dataset or a document, such as permitted purposes, territories, recipient kinds, expiry, retention and whether AI may process the data, are enforced in every run and printed in every file.

Source reliability and agreement between systems

Sources often state their own reliability, for example as an Admiralty-style grade. Those grades are read on arrival and become the starting point of the source’s accuracy in the analytic source registry, which its own checks and corroboration can then move. When two systems disagree about the same figure, the organization’s precedence rules decide which wins for that field or metric, effective-dated, and scheduled reconciliation pairs report where two systems agree, differ or miss each other. Units and currencies are compared strictly and convert only under a declared factor or a dated rate.

When sources change their minds

Three controls deal with content that changes after analysis has used it. Closed periods are fingerprinted, so when a source restates a past month, an alert names the reports that read it and their owners are told. A received report can be marked withdrawn or corrected, after which it leaves search and fact lookup and the products that cited it receive a challenge. And one report arriving through two feeds must not count as two independent sources: each document keeps a winnowed fingerprint of its word n-grams [32], and documents that largely repeat each other count once in corroboration.

Encrypted, signed and damaged files

Every file passes a gate before any parser reads it: its type is decided by content rather than extension, a malware scan fails closed, archives are walked within limits on size, ratio, depth and count, and macros are held. Files protected for transit are opened with the organization’s own keys or grants, including OpenPGP, S/MIME, data-centric formats and sensitivity-label protection, and signatures are checked against the senders the organization registers. Damaged files, such as truncated PDFs, broken archives and corrupted Office, text, JSON and XML files, are repaired automatically where possible, and what was lost is counted and shown rather than hidden; a PDF that cannot be repaired is read page by page from its images. Content inspection looks for data the organization must not hold and acts per rule, keeping its findings as counts, never as values.

Facts from documents

Values extracted from contracts, clinical records and reports must quote the passage they came from, and code must find that quote verbatim on the cited page. A text pass and a vision pass read each document independently; disagreements go to a person, shown beside the page. A value whose quote cannot be found is not a fact.

9Controlled dissemination

In regulated work, a correct report sent to the wrong person is still a breach. Encryption and labels control who can open a file; they do not record who decided to send it, to whom, for what purpose, or whether it came back. DataLogiX treats each act of sharing as a decision to be made once, by one component, and recorded.

Labels on a lattice

Markings are elements of a lattice: a level, categories, flags and release lists, with a join that takes the highest level, the union of categories and the intersection of release lists [8, 33]. Marking packs define the levels and controls for schemes such as CUI, NATO markings, UK Government Security Classifications and TLP. A provider serving several clients carries each client as a category, so one client’s label can never reach another client’s channel. Portion marks and banners are computed from the labels of each element’s sources; a person approves the product marking.

One gate, three acts, three tiers

Every route that returns content declares whether it shows a view, makes a copy or issues a link, and one decision core answers it, in the API and in every delivery channel. The organization’s records pack sets one of three tiers. Standard logs every copy and link. Regulated also asks for a reason and a listed purpose. Controlled needs a release authorization for every act, numbered copies, receipts, and signing before any byte leaves. A tier only ever rises.

Recipients, releases and copies

Recipients are kept in a directory with attestations of clearance, compartments, citizenship and need to know. Where the rules say, a release needs two people, the consent of the originator of controlled information, and a marking approval by a trained approver. Links name one recipient, who must prove their identity and acknowledge the handling rules before opening. In the controlled tier, each recipient receives a numbered copy stamped for them and carrying a hidden fingerprint, so a leaked copy can be matched to its source.

Signed records of every hand-off

Each copy or link writes a transmittal record that is chained to the one before it, signed and timestamped, and verifiable offline. Recalls, confirmations that copies were destroyed or returned, and corrections chain records of their own. The same records answer the questions regulators ask: in health care, the accounting of disclosures under 45 CFR 164.528 [9], where the people a report concerns are traced and kept only as keyed hashes; in criminal intelligence, the dissemination records of 28 CFR Part 23 [10].

Sharing with partners

Partners often enforce access with their own key services. Releases, exports and deliveries can be wrapped in the Zero Trust Data Format through the organization’s OpenTDF platform [34, 35] or protected with Microsoft Purview, required from a marking level upward, and the key service can be asked again before a report page or an assistant’s answer shows content. Labels are read from and written to the partners’ own syntaxes, so a label survives the hand-off rather than being retyped.

AI assistants under the same gate

An assistant that calls DataLogiX acts as the person who signed in and can do no more than that person. Per policy, it receives the full content, the numbers without the report’s text, or a link only. A person’s first purpose for a report is fixed, and repeated refusals lock further attempts. An assistant can prepare a share, but only the person sends it.

10Expert packs: rules as signed content

What makes a report acceptable differs by sector: payment formulas and small-count rules in health care, analytic standards in intelligence, dissemination rules in law enforcement, reconciliation and disclosure rules in finance. Encoding these in the product’s code would make every sector change a software release and every customer variation a fork. DataLogiX keeps them as expert packs: signed, versioned content that a kernel resolves without knowing what any rule means.

There are twelve kinds of pack, covering domain terms and rule tables, metrics and suppression rules, collection and source precedence, report products, writing style, analytic standards, markings, access, records and dissemination, review workflows, approved calculations, and the models an organization allows. Rules are written as type-checked expressions, effective-dated tables and policies in a formal authorization language, and every pack must pass its own golden tests before it can be built.

Each pack version is a deterministic, signed artifact distributed with update metadata that refuses rollback and expired versions, and every version is certified before signing: validation, golden tests, determinism and, for packs that carry code, stress and sandbox-escape probes. Pinning a version needs one administrator to propose and a second to approve. Before a candidate is switched on, it is evaluated against the organization’s stored reports, showing which markings, banners, rules, terms and small-count decisions would change. Offline mirrors carry packs to disconnected sites.

11Isolation, models and deployment

Each organization has its own cloud project, keys and service identities. Every database transaction carries a signed organization context, and row-level security is forced on every tenant table, so a query that forgets its scope returns nothing rather than another organization’s rows. Every endpoint is tested with another organization’s credentials and must answer “not found”. Providers that serve clients get a second wall per client, with its own key, dataset, people and usage. Sensitive columns are sealed per organization, keys rotate, and leaving destroys an organization’s keys so that its data can no longer be read.

Models are named by alias in one lineup, and changing a model behind an alias requires its evaluations to pass. Prompts are versioned and locked. Health data goes only to models and services cleared for it, through an input and output screen that fails closed, and logs and telemetry are scrubbed. A contract can exclude a model family entirely. Every authorized request writes exactly one audit event, and a failed audit write fails the request.

The same design runs as a managed cloud service, on customer-managed storage, in a private data center, disconnected with no call-home, in a government enclave with smart-card sign-in, or on a forward node at the tactical edge that works disconnected and syncs with the rear, with models chosen to fit: frontier models where contracts allow, or open-weight models served inside the customer’s own installation.

12How the claims are tested

A design like this is only as credible as the evidence that its checks work. We distinguish checks that are deterministic, which can be shown to hold by tests, from checks that rely on a model, which can only be measured.

• Offline tests. The change gate runs with the network blocked. Model calls replay recorded answers keyed by a hash of the request, and a missing recording fails the test. Contracts are checked in both of the system’s languages, and workflow histories are replayed to prove determinism.
• Certified references. Statistics are compared with NIST’s certified values [13] and with published worked examples; key functions are compared with formal reference implementations.
• Adversarial corpora. A corpus of hostile queries against the guard in every dialect; hostile files such as archive bombs, malware samples and encrypted archives; documents carrying prompt-injection text; an attack suite against the flow policies; the cross-organization isolation suite; and planted identifiers that must never reach a log or telemetry export.
• Audit sets for model-based checks. Each check that relies on a model is measured on sets with planted errors, split into calibration and test sets, and reported with confidence intervals [22]. Thresholds are set by split conformal prediction [36], and nightly runs raise an alarm when rates drift outside their intervals.
• Live evaluations and public benchmarks. Nightly and on-demand runs against live models, with spending caps, alongside public benchmarks for text-to-SQL [16, 17] and contract review [37].

The principle is that a model-based check is measured, never trusted, and that the system is arranged so a model can add a finding or send work to a person but cannot clear a rule’s finding.

13Limitations

Several limits follow from the design itself, and readers should weigh them.

• Recomputation needs a second path. Values from model-written code, SQL results without an agreeing candidate, and some float sums whose error bound is too wide cannot be recomputed. They are held as degraded and need a person, so the burden of review falls on people exactly where automation cannot help.
• The sentence check is a model. Rules check every number, binding, caveat and marking in code. Whether a sentence’s meaning is supported by its evidence is judged by a model whose verdict can veto but never approve. Its sensitivity is measured, not proven, and planted errors are cleaner than real ones.
• Markings are computed, not authoritative. Portion marks and banners follow the organization’s marking pack. If the pack is wrong, the marks are wrong in the same way everywhere. DataLogiX is not a classification authority, and a person approves every product marking.
• Ingest marks depend on what the file says. A file that carries no marking and comes from a source without a declared floor is held only where the marking pack requires a marking.
• Isolation is tested, not formally proven. Tenant and client isolation is enforced by row-level security with signed context and by policy, and exercised on every change, but has no formal proof.
• Language. The checks for spelled-out numbers cover English.
• Cost. Assurance costs time. A verified report takes minutes rather than seconds, which we accept in exchange for a report a reviewer can check line by line.

14Related work

Natural language to SQL. Spider evaluates clean, cross-domain schemas [16]; BIRD adds dirty values and large databases and shows how much harder realistic data is [17]. Commercial assistants answer questions over one platform’s data. Our approach differs in writing several candidates natively in the source’s dialect, guarding each with a parser, and resolving disagreement with distinguishing data rather than a model’s preference.

Semantic layers. Metric layers define metrics once and compile them to queries. Ours additionally drafts definitions from a source and checks joins against the live data before publishing.

Verification after rendering. We are not aware of public documentation of a system that reads its own Office and PDF outputs back to check every number against a value registry, or that recomputes each published value by an independent path.

Provenance and content credentials. W3C PROV defines a general model of provenance [24]; C2PA binds provenance to media files [25]. Our trace applies these ideas at the level of individual report elements and the checks each passed.

Information flow. Lattice-based models of secure information flow [8] and decentralized labels [33] underpin our labels and flow policies; we apply them to analytics pipelines that include model prompts and rendered files.

Statistical disclosure control. Primary and complementary suppression and the audit of suppressed tables are established in official statistics [20, 21]; our contribution is to run them, in exact arithmetic, inside every report that publishes counts about people.

Analytic tradecraft. Heuer’s structured techniques [3], ICD 203 [1], the UK yardstick [4], IPCC guidance [5] and GRADE [7] define how analysts state likelihood, confidence and sources. We encode them as packs that code checks, rather than as instructions in a prompt.

Data-centric security. The Zero Trust Data Format and OpenTDF bind policy and keys to the data object itself [34, 35]. We integrate with them at the point of release and add the record of who decided each release.

15Conclusion

AI-assisted analytics can be made fit for regulated work, but not by trusting a better model. It needs a design in which a model never types a number, every number is computed twice and read back from the file, analytic standards are rules rather than requests, and every act of sharing is decided once and recorded. Where a rule can be written, code enforces it on every input. Where judgment is needed, models work within structure that code can check, and their contribution is measured. The result costs minutes per report and asks people to decide the cases automation cannot, in exchange for reports a reviewer can check line by line and a record that shows who received what, and why.

References

1. Office of the Director of National Intelligence. Intelligence Community Directive 203, Analytic Standards (2015, as amended). dni.gov
2. Office of the Director of National Intelligence. Intelligence Community Directive 206, Sourcing Requirements for Disseminated Analytic Products. dni.gov
3. Heuer, R. J. (1999). Psychology of Intelligence Analysis. Center for the Study of Intelligence; and Heuer, R. J., & Pherson, R. H. (2010). Structured Analytic Techniques for Intelligence Analysis. CQ Press.
4. UK Professional Head of Intelligence Assessment (2025). Explaining Uncertainty in UK Intelligence Assessment: the Probability Yardstick and Analytical Confidence Ratings. gov.uk
5. Mastrandrea, M. D., et al. (2010). Guidance Note for Lead Authors of the IPCC Fifth Assessment Report on Consistent Treatment of Uncertainties. IPCC. ipcc.ch
6. OASIS. STIX Version 2.1. oasis-open.org
7. Guyatt, G. H., et al. (2008). GRADE: an emerging consensus on rating quality of evidence and strength of recommendations. BMJ 336, 924–926. doi.org/10.1136/bmj.39489.470347.AD
8. Denning, D. E. (1976). A lattice model of secure information flow. Communications of the ACM 19(5), 236–243. doi.org/10.1145/360051.360056
9. 45 CFR 164.528, Accounting of disclosures of protected health information. ecfr.gov
10. 28 CFR Part 23, Criminal Intelligence Systems Operating Policies. ecfr.gov
11. NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations. csrc.nist.gov
12. FBI Criminal Justice Information Services. CJIS Security Policy. le.fbi.gov
13. NIST. Statistical Reference Datasets. itl.nist.gov
14. Unicode Consortium. Unicode Technical Standard #39, Unicode Security Mechanisms. unicode.org
15. Higham, N. J. (2002). Accuracy and Stability of Numerical Algorithms, 2nd ed., ch. 4. SIAM. doi.org/10.1137/1.9780898718027
16. Yu, T., et al. (2018). Spider: a large-scale human-labeled dataset for complex and cross-domain semantic parsing and text-to-SQL. EMNLP. arxiv.org/abs/1809.08887
17. Li, J., et al. (2023). Can LLM already serve as a database interface? A big bench for large-scale database grounded text-to-SQLs. NeurIPS. arxiv.org/abs/2305.03111
18. Holm, S. (1979). A simple sequentially rejective multiple test procedure. Scandinavian Journal of Statistics 6(2), 65–70. jstor.org/stable/4615733
19. Benjamini, Y., & Hochberg, Y. (1995). Controlling the false discovery rate. Journal of the Royal Statistical Society B 57(1), 289–300. doi.org/10.1111/j.2517-6161.1995.tb02031.x
20. Langsrud, Ø., & Lupp, D. GaussSuppression: Tabular Data Suppression using Gaussian Elimination. Statistics Norway. cran.r-project.org/package=GaussSuppression
21. Hundepool, A., et al. (2012). Statistical Disclosure Control. Wiley. doi.org/10.1002/9781118348239
22. Wilson, E. B. (1927). Probable inference, the law of succession, and statistical inference. Journal of the American Statistical Association 22(158), 209–212. doi.org/10.1080/01621459.1927.10502953
23. Brier, G. W. (1950). Verification of forecasts expressed in terms of probability. Monthly Weather Review 78(1), 1–3.
24. W3C (2013). PROV-O: The PROV Ontology. w3.org/TR/prov-o
25. Coalition for Content Provenance and Authenticity. C2PA Technical Specification. c2pa.org/specifications
26. de Moura, L., & Ullrich, S. (2021). The Lean 4 theorem prover and programming language. CADE-28. lean-lang.org
27. de Moura, L., & Bjørner, N. (2008). Z3: an efficient SMT solver. TACAS.
28. Barbosa, H., et al. (2022). cvc5: a versatile and industrial-strength SMT solver. TACAS.
29. ETSI EN 319 142-1, PAdES digital signatures. etsi.org
30. NIST FIPS 204, Module-Lattice-Based Digital Signature Standard. csrc.nist.gov/pubs/fips/204/final
31. NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard. csrc.nist.gov/pubs/fips/203/final
32. Schleimer, S., Wilkerson, D. S., & Aiken, A. (2003). Winnowing: local algorithms for document fingerprinting. SIGMOD. doi.org/10.1145/872757.872770
33. Myers, A. C., & Liskov, B. (2000). Protecting privacy using the decentralized label model. ACM Transactions on Software Engineering and Methodology 9(4), 410–442. doi.org/10.1145/363516.363526
34. Combined Communications-Electronics Board. ACP-240 Edition A, introducing the Zero Trust Data Format (ZTDF).
35. OpenTDF. OpenTDF specification and platform. opentdf.io
36. Angelopoulos, A. N., & Bates, S. (2021). A gentle introduction to conformal prediction and distribution-free uncertainty quantification. arxiv.org/abs/2107.07511
37. Hendrycks, D., et al. (2021). CUAD: an expert-annotated NLP dataset for legal contract review. arxiv.org/abs/2103.06268

How to cite: EVAS. Models propose, code decides: verified, traceable and controlled analytics for regulated work. DataLogiX white paper.