Lower the risk of saying yes.
A proposed thirty-day evaluation on one program and one supported rig. It begins once technical readiness is confirmed. Scope, data custody and acceptance criteria are agreed in writing first.
The structure
Anchor
Thirty days, four phases.
If a required interface is unavailable, the scope is revised before integration continues.
Evidence ladder
State the level. Do not assume it.
- Architecture reviewDocumentation walkthrough under NDA; establishes design intent.
- Harness-only resultA standalone test on a bounded workload, labelled until runtime integration.
- Integrated, pinned replayReconstruct the workload inside its recorded environment; compare checkpoints.
- Controlled fault detectionSeeded faults must produce explicit mismatches, not silent passes.
- Independent reproductionA second engineer repeats the workload from written instructions.
This site presents architecture and proposed evaluation scope, not reports of completed runs. Advancing a level needs readiness on both sides. If prerequisites are missing, rescope or stop—and retain that decision as a finding.
What we would measure
Anchor
Six metrics to agree. Not results.
These are the metrics an evaluation would use. No targets are set here and no results are implied. Each is defined with you before any build.
| Metric | What it tells you | Agreed in advance |
|---|---|---|
| M.01Capture overhead | Runtime, storage and data volume added by the evidence layer. | Metric to agree |
| M.02Checkpoint match rate | Recorded checkpoints that reconstruct inside the agreed environment. | Metric to agree |
| M.03Time to first divergence | Elapsed investigation time from a challenged event to the earliest mismatch. | Metric to agree |
| M.04Replay completion | Bounded histories that complete without an unexplained gap. | Metric to agree |
| M.05False-positive rate | Benign events incorrectly surfaced for investigation. | Metric to agree |
| M.06Storage per unit of work | Bytes stored for each unit of work the workload defines. | Metric to agree |
Each metric is measured against a paired baseline of the same workload without the evidence layer.
Acceptance gates
Anchor
Agreed before building.
Gates are written down before integration starts. They are set against your baseline, so nobody is judging a result they did not define.
Replay is an evaluation objective within a pinned environment. A passing gate describes that environment and that workload only.
- Each gate names a metric, a method and a threshold.
- Thresholds are set after the baseline and before the scored run.
- A second engineer repeats the pinned workload and compares the reports.
- Known limitations and open issues are listed with the findings.
Data custody
Anchor
Your data stays under your terms.
Data custody, retention, NDA terms and access are agreed in writing before the evaluation begins. Nothing is uploaded until they are.
- Who holds the data, and where.
- How long anything is retained, and how it is deleted.
- Who may see the records, and under which terms.
- What may leave the perimeter, and under which permissions.
Questions
Anchor
Questions that survive the room.
01Is CertainTIQ a log or audit tool?
No. Logs describe what happened after the fact. CertainTIQ is designed to check policy and emit an audit record before work is released, and to link each recorded state to its causes.
02Does replay reproduce model outputs exactly?
Replay is an evaluation objective within a pinned environment. It compares execution assignment, policy outcomes, event sequence and lineage hashes. GPU numerical drift is judged against a recorded tolerance.
03Do existing systems need to be rewritten?
The design is intended to bring current pipelines, scripts and databases under one governance model. Integration work is scoped in each evaluation. Drivers, kernels and libraries remain part of a deployment.
04What does zero-hop mean?
Validation, policy enforcement, scheduling and audit emission sit inside one in-process boundary before hardware dispatch. It does not mean zero physical network or device transfers.
05Do hashes prove that the inputs were true?
No. A hash gives a reference for comparison. It does not by itself prove input truth, independent custody or model correctness.
06Is CertainTIQ certified or compliant?
No certification is claimed. CertainTIQ is in development. An evaluation produces records that your risk and compliance teams can examine against your own requirements.
07Which hardware does it support?
The design addresses CPU, GPU, FPGA and AI accelerator classes on off-the-shelf hardware, independent of any single interconnect. Supported devices are confirmed per evaluation.
08Where does the evaluation run?
On one supported rig, within boundaries agreed in writing. Hosting, data custody, retention and access are settled before the evaluation begins.
09What does the evaluation cost?
Scope and terms are set in the briefing and agreed in writing before any build. The evaluation is proposed on one program and one supported rig.
10How is the architecture protected?
It is supported by an active intellectual-property program. Details are shared in private briefings.
Private briefing, under mutual NDA
Anchor
Request a private briefing.
A session with the CertainTIQ engineering team. We walk through the architecture, run the instruments against your questions and scope whether an evaluation makes sense.
- An architecture walkthrough under mutual NDA.
- Answers to a written diligence question list: architecture, integration, evidence, deployment and IP documentation.
- The application guide that fits your question, and what a first bounded evaluation would take.