Skip to content
fluidzero

Approach · how the products are built

Cite it, derive it, or don’t say it.

Construction runs on documents that get disputed and records that get audited. Software for it has to be checkable, so we build to eight principles, each enforced by something in the product rather than promised on a page. Here they are, with what enforces them and where they show up.

IWhat we say

An answer is only as good as the way you can check it.

01

Cite every claim

An answer about a tender is only useful if someone can check it before it goes into a bid. So a claim in a Fennec answer names the blocks of the document it rests on, and each block resolves to a document, a page, a box on that page and the quoted text. Extracted fields carry the same, with a confidence score.

The same rule holds where there are no documents. A Kosh total opens to the bills and obligations behind it; a Chainage stretch opens to the inspection that colours it.

Where it shows

Fennec
Citations resolve to page, box and quote; the cited page opens with the passage highlighted
Kosh
Every chart and total opens to the lines behind it
Chainage
Every stretch names its controlling inspection and the tests it was judged on
  1. 01 · Claim

    “A bid security of 2% of the bid value…”

  2. 02 · Cites

    block d1 · b212

  3. 03 · Resolves to

    Vol. 1 · page 14 · clause 19.1

  4. 04 · Box

    0.11 0.38 → 0.89 0.45 of the page

  5. 05 · Quote

    “…a bid security in the form of a bank guarantee, in the amount of two per cent (2%) of the bid value.”

Fig. A.1The citation contract: a claim names a block; the block resolves to a page, a box on it and the quoted text.Illustrative ids and values

02

State the uncertainty

Software that is unsure should say so, in words, where the user is looking. A progress bar that animates over a state nobody can measure is a small lie, and small lies teach people to stop reading the screen.

Fennec runs every question inside limits on steps and time, and if a limit stops the search the answer says so. Kosh keeps the contractual date and the expected date apart, and marks every expectation as an estimate. Chainage draws a progress fraction only when bytes were actually measured, and names a stalled or unreachable reader as what it is.

Where it shows

Fennec
Answers carry the reason a search stopped; a reply cut off at its limit is marked as cut off
Kosh
Estimates are labelled; overdue is computed from the contract, never taken as a sign a bill will not be paid
Chainage
No simulated progress; stalled, unreachable and failed are distinct states with distinct actions
IIWhat we keep

Records get audited. Build them as if they will be.

03

Derive, don’t store

A status that someone types is a second copy of the truth, and second copies drift. Chainage stores inspections, never the colour of the road: each stretch is computed from the inspections covering it every time the road is drawn. The newest attempt controls; a tie resolves to the worse result, so it can never hide a failure.

The rules live in one package that both the browser and the server run, so what the screen shows is what the server will enforce, and the two cannot disagree.

Where it shows

Chainage
Cell status, the evidence gate and layer sequencing are one shared, tested package
Kosh
One calculation layer feeds every screen, so totals agree wherever they are read
  • Inspection 1031Rejected14 Jul
  • Inspection 1040Approved23 Jul

newest covering attempt controls
tie → worse result wins
neighbours never repaint

Approvedcomputed each time it is drawn
Fig. A.3Nobody sets the colour. A rejection followed by an approved re-test of the same ground: the newer attempt controls, and the rejection stays on record.Illustrative inspections

04

Freeze the rules at the time of work

A stretch approved in March was approved against March’s acceptance limits. If the catalogue changes in June, March’s approval must still read as it did. So a Chainage inspection keeps a snapshot of the rules it was raised under, and an activated configuration cannot be edited: a change makes a new version, and history is never re-judged.

Where it shows

Chainage
Raise-time rule snapshots; versioned configuration, read-only once in force

05

Never rewrite the record

Chainage keeps three append-only logs: who changed a record, who opened one, and what the document reader was asked and answered. The database refuses a rewrite; it is not left to convention or good intentions.

Fennec keeps the raw output of every document it reads and every exchange with the services that read it, so a past result can be explained, audited and reprocessed without reading the document again.

Where it shows

Chainage
Audit, access and reader logs, append-only, enforced by database triggers
Fennec
Raw parser output and every provider exchange kept
IIIHow we know

Believe the benchmark, not the demo.

06

Structure before similarity

Tenders are organised by numbered clauses, schedules and sheet ids, and the questions bid teams ask often span a whole set. Fennec therefore has no embeddings and no vector store: it answers by navigating the outline, the clause numbers and the references, with full-text search alongside.

We tested the idea before we built on it. In our published benchmark, top-k retrieval answered none of the four questions that required counting across a document set: it cannot count documents it never fetched. Only the agents that navigated could say which page an answer came from.

Where it shows

Fennec
Five navigation tools: outline, find, read, view page, follow a reference

Similarity search

Fetch the eight passages most like the question.

“How many filings name this debtor?” is a property of the whole set. Eight passages cannot answer it, however similar they are.

Navigation by structure

Follow the outline, the clause numbers and the references.

Every step is a place in the document, so the answer can say exactly where it came from, and what it did not reach.

Fig. A.6Fetching the passages most like a question, against walking the document’s own structure.Illustrative

07

Measure before believing

We write down what success means before we tune for it, test on documents the system has not seen, and count invented values as a failure of their own rather than averaging them away. The published benchmark used the same model for every system and scored by deterministic comparison, with no model judging another.

And we publish where we lose. That benchmark opens with the finding that a single prompt matched months of our own engineering on short documents.

Where it shows

Research
Benchmarks state their sample, their method and their failures
Fennec
Extraction is benchmarked against acceptance criteria fixed before tuning

08

Let the architecture enforce itself

Rules that live in a document erode. So the boundaries that matter are tests that fail the build: in Chainage, which packages may depend on which, where a vendor’s name may appear, and how large a file may grow. In Fennec, document-reading vendors sit behind a neutral interface, so one can be replaced, and the raw responses replayed through the new mapping, without paying to read everything again.

Where it shows

Chainage
Architecture fitness tests run in CI
Fennec
Vendor-neutral ports for parsing and extraction
What we will not claim

The claims you will not find here.

Restraint is a form of evidence. These are the things we deliberately leave off this site, and why.

01Certifications we do not hold
We do not hold SOC 2 or ISO 27001 today, and we will not show a badge we have not earned.
02Accuracy percentages for the products
Product accuracy depends on your documents. Our published research states its sample, its method and where we lost.
03Customer logos, quotes or data
We name the companies we work with. We show no customer’s logo, quote, figures or documents without their written permission.
04Sample data as real data
Every figure on this site that shows product data is labelled. Illustrative figures describe no real project, contractor or person.
05Readiness we have not reached
Each product’s status sits next to its name, in plain words: in pilot, in trial, in early access.
Next step

Check our work on documents you already know.

The fastest way to judge software that claims to show its work is to test it where you already know the answer. Bring a tender you have bid, or a stretch of road you have inspected.