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.
The product / Veritas / The request layer for enterprise software
Anyone can ask for a tool.
Only the right ones get built.
Veritas sits between the person who needs a tool and the developer or coding agent who builds it. It takes a plain-language request and works out whether it should be built, whether something the organization already owns does the job, which rules apply, and who has to decide. Then it hands the builder a locked contract, checks what comes back, and keeps watching once it is in production. The request stays one governed record the whole way.
Where it sits
Between the asker
and the builder.
Most organizations either make the business write a specification before anyone has looked at the evidence, or let a prompt-to-app tool build whatever was typed. Veritas asks for a short, truthful observation and a desired outcome, then does the looking.
Everything that follows attaches to that one record, with the status and review cycle that held when it happened: intake revisions, the authorities in force, control attestations, exceptions, approvals, releases, and production observations. The developer or coding agent receives a build contract compiled from the record, not a chat transcript, and an independent verifier checks what comes back. 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.
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.
Use cases
The record is general.
The evidence is local.
Veritas carries the same governed record through any kind of request. What changes from one use case to the next is the corpus it searches, the authorities in the registry, and the shape of the assessment it generates. See who it serves
ConstructPolicies is the flagship use case: 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