PeakLogic Field Evidence Loop — Build Journal
A short record of the moments that changed the project as it moved from a field observation toward a working, testable evidence system.
Update 1 — From Idea to Executable Evidence Loop
Why we deliberately built deterministic evidence mechanics before training a model.
We started with a simple field problem: important proof is often requested after the work has already changed or concealed it.
Instead of immediately training a model, we first built the mechanics around the evidence itself — work orders, proof requirements, evidence state, quality checks, missing-proof requests, reminders, escalation and human review.
That gave computer vision somewhere meaningful to operate.
What changed: The project moved from an idea about recognizing construction evidence to an executable evidence workflow.
Update 2 — Real Field Media Broke Our Video Sampler
The 98-second walkthrough bug, why it mattered, and how the real job helped us repair it.
When we tested PeakLogic against a real construction walkthrough, we discovered that our bounded video sampler could fill its candidate quota too early and miss the final portion of a longer video.
The test media did exactly what real field evidence should do: it exposed something our controlled tests had missed.
We changed the sampling strategy to preserve coverage across the full video and added a regression test so the same failure cannot quietly return.
What changed: Real field evidence stopped being demonstration material and became part of the engineering process.
Update 3 — Evidence Must Belong to a Job
Why Trial 001 caused us to introduce JobEvidenceRecord / JobEvidenceSession and reject unbound media.
A construction photo is not useful evidence simply because it looks correct.
We need to know which job it belongs to, which work order required it, and which proof point it is intended to support.
Trial 001 made that boundary much clearer. PeakLogic now rejects free-floating media before it can change EvidenceState.
What changed: Visual similarity alone is not proof. Provenance became part of the Evidence Loop.
Update 4 — What Happens When the AI Doesn't Know?
Failure handling, UNKNOWN behavior, human escalation, and why missing proof cannot be invented later.
Real field evidence is messy. Views can be incomplete, images can be blurred, scenes can look similar, and sometimes the system simply does not have enough information.
We therefore treat uncertainty as a legitimate system state rather than something the model must hide.
Depending on the evidence, PeakLogic can request another view, reject poor evidence, flag missing proof or escalate to a human.
What changed: Knowing when not to make a decision became part of the intelligence of the system.
Update 5 — The Work Order Proved the Problem Exists
The real construction packet showed that “proof before concealment” is not an invented AI use case.
Our real Trial 001 work order contains explicit photographic documentation requirements tied to the actual job.
That was an important moment for the project.
We were no longer designing around a hypothetical construction problem. The documentation requirement already existed in the customer's workflow.
PeakLogic is attempting to make that requirement easier to capture, organize and verify before the opportunity for proof disappears.
What changed: The product thesis was validated against a real operational requirement.
Update 6 — From Mechanics to Measured Vision
The architecture is becoming stable. Now the visual system has to prove itself.
We have spent significant time establishing the Evidence Loop, failure behavior, job binding, traceability and human-review boundaries.
The next phase is different.
Representative field evidence now needs to enter OpenCV 5, produce bounded observations, change EvidenceState, trigger an appropriate next action or escalation, survive meaningful failure cases, and leave a reproducible trace.
We also still need to demonstrate the final execution path on AWS.
What changed: The question is moving from “Can we build the loop?” toward “How well does the vision perform inside the loop?”
Where We Are Now
The center of the project is becoming much clearer:
Capture the right evidence, for the right work, at the right place and time — before the work changes or conceals it.
And our development cycle is becoming equally clear:
Build → Run → Observe → Break → Trace → Repair → Retest → Measure → Document.
Log in or sign up for Devpost to join the conversation.