Notes

Two more provisional filings: what happens when the rules or the evidence change

The original verification work answered one question, and answered it
reasonably well: is this output or decision allowed? A deterministic lane
takes the output, applies machine-readable rules and returns a categorical
verdict rather than a confidence score.

Working through how that lands inside a regulated organisation made something
obvious that had not been obvious before. Answering that question at a single
point in time is only the first round of the problem.

The two questions that come after

Most verification systems focus on whether something is correct or compliant
right now. Far fewer address what happens afterwards, when one of the two
things the answer depended on moves underneath it.

A governing rule changes. A regulation is amended, a policy is updated, an
internal control is tightened. Every decision made under the previous version
is now sitting on a superseded basis. Which of them actually matters? Which
approvals need revisiting? Which can be left alone?

The underlying evidence changes. A dataset is revised, a reference record is
superseded, a source is corrected. Downstream sit conclusions that depended on
the old version. Some of them are now wrong. Most of them are probably fine.
Working out which is which, by hand, is the expensive part.

For a regulated organisation both of these happen constantly, not occasionally.

What was filed

Two further Australian provisional patent applications were filed on 16 August
2026, joining the two already on file:

  • DCLA, Deterministic Control Lineage Architecture. The governing rules
    changed. What does that affect?
  • DELA, Deterministic Evidence Lineage Architecture. The underlying evidence
    changed. What does that affect?

Together with the original two, the architecture now spans four connected
layers rather than one. A control change flows through DCLA. An evidence change
flows through DELA. The resulting output is checked through DTL. Where that
decision drives a physical system, DAX governs whether the action executes.

Why the lineage half is the harder half

Detection is not the difficult part. Version control already tells you that
something changed. The difficult part is consequence: separating the
downstream work that genuinely depended on the part that changed from the work
that did not.

Getting that wrong in either direction is expensive. Under-flagging leaves
invalid conclusions in place, which is the safety failure. Over-flagging
triggers broad revalidation that consumes expert time nobody budgeted for,
which is the economic failure. A system that flags everything is technically
safe and commercially useless.

So the measure that matters is not detection rate. It is affected versus
preserved accuracy
, measured in both directions, and it is the number any
pilot of this work should be judged on.

The caveat that applies to all four

None of the four filings has undergone a formal freedom-to-operate search. That
work is planned and has not happened. A prior art note prepared earlier this
year concluded that the individual mechanisms are not novel in isolation, and
that the open question is whether the specific combination is obvious. That is
a harder test and a different one, and it is exactly what a formal search
exists to answer.

Provisional applications are filed, not granted. We would rather state that
plainly than let the word "patented" do work it has not earned.

Start with one workflow

Thirty minutes on a workflow where a change in rules or evidence has already cost you work.

Next · See it work AI Control Tower