Causalytics
  • Briefs
  • Veritas
  • Specifications
  • About
  • Contact
Skip to main content

The product / Veritas

Demand enters once.
Its evidence stays attached.

Veritas takes a business observation and carries it, as one record, through the evidence found, the assessment generated, the controls that apply, the human decisions made, the build that was authorized, and what production later showed. It works in any vertical, because the record is about the work, not the domain.

Discuss a design partnership ↗

The unit of the system

A governed work record,
not a form.

Most intake systems ask the business to write a specification before anyone has looked at the evidence. Veritas asks for a small, truthful observation and a desired outcome, then does the looking.

Everything that follows attaches to that record and keeps the status and review cycle that existed when it happened: intake revisions, the authorities that were in force, control attestations, exceptions, approvals, releases, and production observations. The name is an acronym for what the record holds: Verified Evidence, Requirements, Intake, Traceability, Assessment, and Strategy.

How a request moves

Ten stages.
Each one leaves a trace.

1 / Signal intake

An observation, a desired outcome, a requester, and an early triage of consequence and data. Workflow, shaping, and authority details are optional enrichment, not gates to entry.

2 / Observation

Veritas searches the organization’s strategy, policy, and prior-decision corpus and inventories the tools that already exist, so a request is compared with what the organization has said and built.

3 / Applicability and authority snapshot

Deterministic rules classify whether the work involves AI, consequential impact, federal scope, or contractual flow-down, against a versioned authority registry. The snapshot is frozen with the record.

4 / Assessment

A structured model call generates the questions, gaps, and evidence requirements specific to this request. Anything the evidence does not support stays unknown and becomes a requirement, never a false answer.

5 / Portfolio strategy

The request and its assessment are related to organizational strategy, related work, and observed evidence: priority, sequencing, dependencies, and the conditions for success.

6 / Control gates

Strategic alignment, evidence completeness, the adopted ISO/IEC 42001 scope and Statement of Applicability, NIST SP 800-53 and AI RMF candidates, consequential-AI contestability, and applicable OMB M-25-21 practices. A gate passes on reviewed evidence, not on a model’s confidence.

7 / Build contract and factory

The governed packet is compiled into a build contract. The factory materializes a bounded application project, validates its exact file envelope, syntax, and package boundaries, and fingerprints every file. It never executes what it generated.

8 / Human review

Attestations are recorded by required role for the current cycle. Waivers and overrides need a separate named approval and an expiry date.

9 / Monitoring

Production observations are appended to the same record. A breach opens reassessment and records the observation that caused it.

10 / Audit

The end-to-end lineage, from the first revision of the request to the latest production observation, with the authorities, controls, exceptions, approvals, and releases that applied at each step.

What each part may not do

Boundaries are
part of the design.

Every control plane in Veritas has a stated prohibition, and the prohibitions are as important as the capabilities.

Intake may not dictate an unexamined technical solution. The knowledge layer may not manufacture evidence that was not observed. Assessment may not collapse unknown into false or ready. Governance may not retroactively decorate work that was already built. Build may not expand scope beyond the authorized contract. The factory may not execute, publish, or authorize deployment of what it generated. Human review may not approve without an attributable rationale. Monitoring may not detach telemetry from the intent that authorized deployment.

Where the model stops

Semantics to the model.
State to the code.

Language models are used where interpretation is unavoidable: shaping the assessment, relating a request to strategy, identifying candidate reuse, and organizing evidence into a proposed contract.

Deterministic code owns the state machine, required fields, persistence and audit events, gate semantics, deployment authorization, monitoring records, generated project paths and manifests, and every fallback. Retrieval runs before the structured model call and is persisted as evidence, so the model reasons over what was found rather than deciding what exists. When model services are unavailable, the workflow degrades to deterministic behaviour instead of disappearing.

Authorities as data

Legal force and technical relevance
are different columns.

A versioned registry records what each standard or rule is. A separate, change-controlled organizational profile records whether this organization has adopted it, for what scope, under whose authority, and from what date.

ISO/IEC 42001 is treated as the certifiable management-system standard it is: voluntary by default, binding inside a declared scope once adopted or required by contract. An unresolved adoption decision blocks AI work from the build lane; a requester or a model cannot declare adoption. NIST AI RMF, NIST AI 600-1, and SP 800-53 remain versioned voluntary candidates until an accountable adoption decision. OMB M-25-21 activates only for explicitly established federal high-impact AI or a documented flow-down. Draft and initiative material can be watched but can never block. Licensed standard text is not copied; the registry holds identifiers, short paraphrases, and official source links.

Verticals

The record is general.
The evidence is local.

Veritas carries the same governed record through any domain. What changes per vertical is the corpus it searches, the authorities in the registry, and the shape of the assessment it generates.

ConstructPolicies is the first vertical: a requirements research workbench for restoration and reconstruction teams that connects project facts to candidate requirements and the source passages available to review them, with coverage assembled and audited per jurisdiction. See ConstructPolicies →

In healthcare, the same discipline appears in the weekly briefs and the open Measurement Contract and Impact Passport specifications, which fix an evaluation question before the analysis and carry the result with its limits.

Status

Working, early,
and honest about it.

Veritas runs today as a single-node system with the full flow above, a deterministic project factory, and an administrative audit view. It is not yet a production service.

Before multi-user or production use it needs authenticated identity, transactional persistence with immutable artifact revisions, and an isolated runner for executing generated code with no ambient secrets or network access. Its audit lineage is logically append-only, which is not the same as tamper-evident storage. Its static inspection of generated code is defence-in-depth lint, not a security sandbox. These are stated limits, and they set the agenda for the next increments.

Design partners

Bring one request
your organization struggles to govern.

We are looking for a small number of organizations willing to run a bounded, non-sensitive request through the full record and tell us where it breaks.

Contact Causalytics ↗

© 2026 Causalytics Impact · A public benefit company

 
  • Briefs RSS

  • Impact Passport

  • Research foundations

  • ConstructPolicies