Inspiration
Public-sector security requirements arrive as prose, but the evidence needed to answer them is scattered across source code, authentication configuration, deployment files, cloud settings, and organisational records. Bid teams need defensible responses quickly, while engineers and security reviewers must prevent unsupported claims from entering tenders or contracts.
Veritylane helps software suppliers turn tender security clauses into evidence-linked assurance cases without pretending that repository evidence proves compliance.
Its guiding principle is simple:
Compliance claims should be compiled from evidence, not generated from confidence.
What it does
A project-local Codex skill uses GPT-5.6 to preserve the source language, obligated actor, obligation strength, applicability, responsibility, and uncertainty of each requirement.
Deterministic TypeScript scanners then inspect bounded repository and sanitised evidence inputs. Each scoped claim is reported as:
- technical evidence supported (
verified); - partially supported (
partially_verified); - repository evidence missing (
evidence_missing); or - human or organisational evidence required (
human_required).
Every technical finding links to an exact file and line. Veritylane emits structured assessment JSON, an assurance case containing claims, arguments, and evidence, and a self-contained HTML report. The report visualises evidence distribution without producing a compliance score. Legal and contractual conformance remains not_determined.
The workflow is reproducible:
Tender clause
→ GPT-5.6 and Codex structure the evidence question
→ deterministic scanners collect bounded observations
→ the report links technical evidence and assigns human follow-ups
See it work
The video starts with three bilingual supplier requirements: access control, administrative audit logging, and a signed security schedule. The first has repository evidence, the second is only partially supported, and the third requires a person because a repository cannot prove that a contract was signed.
The demo then adds the missing user.role_changed audit event and reruns the same assessment. The technical audit claim moves from partially supported to technical evidence supported. The signed contractual requirement remains human-required. The same evidence contract responds to a real code change without silently turning technical coverage into certification.
How I used Codex and GPT-5.6
Codex was both the development environment and part of the delivered product. It navigated the repository, helped evolve the evidence schema, implemented and reviewed scanners, exercised fixtures, ran tests, and traced report conclusions back to source locations.
The project-local $compile-security-evidence skill defines the assessment procedure, invokes the scanners, checks generated artifacts, and explains unsupported claims without overriding deterministic evidence states.
GPT-5.6 handled the semantic work: decomposing multilingual prose, separating actors and responsibilities, preserving modality, identifying relevant evidence, and recognising questions that repository evidence cannot answer. The model frames the evidence question; deterministic code records what was observed.
Technical highlights
- A project-local Codex skill with an end-to-end evidence workflow.
- An authority-aware multilingual requirement and responsibility model.
- Bounded deterministic scanners with exact repository-relative file and line references.
- Explicit assumptions, counter-evidence, defeaters, and unresolved gaps.
- Assessment JSON, assurance-case artifacts, and a self-contained HTML report, with pinned build-time Flint and Vega-Lite visualisation tooling.
- A core scanner and report pipeline with no third-party runtime dependencies.
- A deliberately mixed 13-requirement sample across all four evidence states, backed by automated tests and Node.js 24 CI on Ubuntu and Windows.
- Veritylane’s 57-record government-source catalogue distinguishes binding regulation, mandatory policy, technical standards, guidance, procurement documents, and official data sources. Each record retains issuer, jurisdiction, language, effective dates, applicability, official locators, and redistribution treatment; government publication alone does not automatically create a supplier obligation.
What I learned
The hardest problem was avoiding false certainty. “Not found” does not always mean “not implemented”: a scanner may lack access, a control may run outside the repository, or the obligation may bind another actor. Provider capability does not prove customer configuration, and technical guidance does not create a contractual obligation.
The strongest use of a reasoning model was not asking it for a confident answer. It was asking it to structure ambiguity, define the evidence question, and recognise where human responsibility begins.
Judge quick test
Clone the private repository and use Node.js 24:
npm ci
npm run demo:raw
Open dist/raw-clause-demo/index.html and follow a technical finding to its exact source location. Run npm run demo for the broader 13-requirement sample or npm run check for the complete verification suite.
No application account, API key, cloud credentials, or source upload is required. The included inputs are sanitised fixtures, and the generated report is self-contained.
What's next
Next steps are structured TypeScript and configuration analysis, expert-labelled false-verification evaluation, versioned evidence diffs, reviewer annotations, and opt-in read-only connectors. Any expansion will preserve the same rule: more evidence cannot silently become a compliance certification.
Built With
- codex
- css
- flint-chart
- gpt-5.6
- html
- node.js-24
- typescript
- vega-lite