PeakLogic Field Evidence Loop

Computer vision that turns field photos and video into verified work evidence, detects missing proof, and escalates uncertainty to humans before critical work is concealed.

Comment 1

Inspiration

PeakLogic Field Evidence Loop grew out of something I was doing long before I knew how to build software: noticing patterns in how work actually gets done.

My background is not a traditional software-engineering path. I have worked in kitchens, shipping and receiving, commercial agriculture, and construction. These are very different environments, but they repeatedly showed me the same thing: there is often a gap between how a process is supposed to work and what actually happens when people are busy doing the work.

I have always noticed those gaps.

For years, that was also frustrating. Seeing a better process was much easier than implementing one. I could recognize recurring problems, missing information, unnecessary work, and communication breakdowns, but I did not yet have the technical skills to turn those observations into working systems.

Over the last year and a half, I began seriously studying software, artificial intelligence, computer vision, and agent-based systems.

Studying computer vision changed how I looked at my everyday construction work. I started seeing a job not only as a sequence of physical tasks, but as a system of states, evidence, decisions, and handoffs.

That is where PeakLogic Field Evidence Loop began.

From an Idea to a Build

The original observation was simple:

Important construction evidence needs to be captured at the right place, at the right time, before the work changes.

A perfect photograph taken too late may be useless.

A simple photograph taken at the correct stage can prevent hours of uncertainty later.

In commercial roofing, work is frequently covered by subsequent layers. Once insulation, membranes, flashings, or other components are installed, important details may no longer be visible.

Photographs help preserve those details, but simply collecting photographs does not establish whether the required evidence exists, whether it is usable, or whether it actually proves what someone needs to know.

That changed the problem for me.

I was no longer trying to build an AI system that simply looks at construction photographs.

I wanted to build a process that connects the work order, the evidence collected, the observations we can support, and the decisions that should follow.

The larger objective became:

Work → Evidence → Perception → Decision → Action → Verification

PeakLogic Field Evidence Loop became a focused implementation of that idea.

Building with AI Systems

There is another part of this project that has been important to me.

I am developing PeakLogic inside a larger experimental approach to organizing and solving complex problems using specialized AI-assisted workflows.

Instead of asking one AI system to research, design, implement, test, and validate everything at once, I have been learning to divide work into smaller responsibilities with defined inputs, outputs, and verification requirements.

Different AI-assisted roles can contribute to research, software development, technical review, documentation, and coordination.

This approach influenced how I designed PeakLogic.

I began separating questions that initially seemed like one large problem:

  • What is the field worker trying to document?
  • What evidence should be available?
  • What can computer vision actually measure?
  • What information must come from a human?
  • What decision can safely follow a measurement?
  • What happens when the evidence is incomplete or unusable?
  • How do we preserve the history of what happened?
  • How can the results become useful to a foreman or project manager?

This decomposition helped me move from a broad concept to software that could be implemented and tested.

The AI-assisted development process is separate from the actual application demonstrated in this competition. The competition implementation uses a defined Python, OpenCV, and persistent-state workflow, not a claim that the entire AI coordination system was deployed on AWS.

How the Evidence Loop Works

The long-term vision is an event-driven system that connects jobsite observations to project requirements and practical follow-up.

Each work order establishes what information or evidence is expected. Field photographs, videos, notes, and supporting records can then be associated with the correct project, workday, or work area.

Computer vision contributes measurable information about visual evidence. Other source records provide the context that an image alone cannot establish.

The system can then preserve observations, identify uncertainty, determine a supported next action, and maintain a traceable project history.

For this competition, I deliberately narrowed that vision to a reproducible technical workflow:

Source-bound field photograph → OpenCV 5 image analysis → Evidence-handling decision → Persistent job history → Traceable report and results.

The distinction between image quality and actual proof is essential.

A clear photograph does not automatically prove correct installation.

A photograph associated with a work order does not prove it was delivered to the responsible manager.

A computer vision measurement does not replace professional judgment.

PeakLogic is designed to preserve those distinctions rather than produce an answer simply because the software can produce one.

What I Built and Tested

For the competition, I implemented a field-evidence processing workflow using Python, OpenCV 5, Docker, SQLite, and Amazon Web Services.

The system connects approved original roofing photographs to a previously established work-order record.

OpenCV evaluates technical image suitability, including image sharpness. That result feeds an evidence-handling decision, which is saved in the existing persistent job record.

The workflow produces state information, event history, reports, traces, and verification receipts that can be independently inspected.

Actual AWS Execution

We processed two original photographs from different days of a historical commercial roofing project in a private AWS EC2 Docker environment.

Photograph 1 — Usable field evidence

  • OpenCV sharpness measurement: approximately 624.403
  • Resulting action: continue_review
  • Meaning: The image was technically usable for further review.

Photograph 2 — Blurred field evidence

  • OpenCV sharpness measurement: approximately 2.465
  • Resulting action: record_quality_exception
  • Meaning: The image had insufficient technical quality, and the historical record needed to preserve that exception.

These images were not a before-and-after comparison. They were separate, source-bound photographs used to evaluate two different evidence-quality outcomes.

Both actions were recorded in persistent SQLite state.

The job history advanced from five events to seven events. The saved state, traces, reports, and receipts were preserved and subsequently checked through an independent container reopening process.

The software also underwent regression testing and controlled failure-handling verification. The accepted integration passed 119 software tests and nine deterministic failure checks.

Those results demonstrate software behavior and reproducibility. They do not represent 119 construction inspections or a measured roofing-defect classification accuracy.

The underlying work-order requirement concerning photograph delivery remained unresolved and subject to human confirmation. Professional acceptance also remained pending.

That was an important result for me: the software made different decisions based on actual visual measurements without inventing evidence that the photographs could not provide.

The Hardest Challenges

The hardest part has not been writing one particular piece of code.

It has been translating the knowledge that exists naturally in an experienced worker's head into something a system can process without pretending every situation is predictable.

Construction is messy.

Lighting changes. Camera angles change. Work gets covered. Two similar-looking photographs can mean different things depending on the stage of installation.

A technically clear image may still be the wrong image for the requirement.

An image may show something important but lack the context needed to interpret it correctly.

I also learned that engineering verification requires more than successful tests. We had to pay attention to original file identity, source hashes, persistent state, reproducibility, the difference between historical replay and new execution, and the limits of what was actually demonstrated.

One important challenge was preserving evidence history without rewriting earlier results simply to produce a cleaner outcome.

Another was distinguishing what a human had reported from what OpenCV had actually measured.

These lessons changed how I think about AI.

The goal cannot simply be to make the system confident.

Sometimes the most useful and correct result is:

There is not enough evidence to establish that conclusion.

That is why uncertainty, explicit human review, source attribution, and traceability have become important parts of the design.

Building from the Field

I have been fortunate to develop these ideas while continuing to work in commercial roofing.

I can spend the day physically doing construction work, recognize a recurring documentation or communication problem, and then return to the project with a concrete example of what the software needs to support.

That connection matters to me.

I understand how much information gets lost between fieldworkers, foremen, office staff, project managers, and technical reviewers.

I also understand that people working in the field do not have unlimited time to complete complicated reporting procedures.

A useful system should reduce unnecessary administrative work rather than create another layer of it.

The field informs the software, and what I learn from building the software changes what I notice in the field.

That feedback loop has become one of the most valuable parts of this project.

What I Learned

The biggest change for me has been realizing that I can now begin implementing things I spent years only noticing.

Computer vision has taught me how physical evidence can be measured, compared, and evaluated.

Software engineering has taught me to preserve state, handle failures, test assumptions, and make results reproducible.

AI-assisted development has taught me how to organize a complex objective into smaller, verifiable responsibilities.

But perhaps the most important lesson is that a useful intelligent system needs to understand its own limits.

More automation is not always the answer.

Sometimes the right contribution is to preserve an unresolved question, identify the missing information, and make the next human decision

Built With

Share this project:

Updates

posted an update —

Journal Note — Why I'm Keeping These Updates

Something I didn't expect while doing this was how useful these updates would become for me personally.

There has been a lot of work happening inside PeakLogic. When you're in the middle of building something, especially when you're testing, finding problems, fixing them and moving on to the next thing, it's actually pretty easy to lose sight of how much the project has changed.

Writing these updates made me stop and look back.

The interesting thing is that some of the most important progress hasn't been a new feature. A lot of it has come from something not working the way we expected.

We put real field material into the system and broke the video sampler.

That sounds bad at first, but it was actually progress.

We learned that evidence can't just be a photo that looks right — it has to belong to the right job.

We learned that sometimes the correct answer from the system is basically, "I don't know yet. I need better evidence."

We learned that the AI shouldn't be the one pretending to approve professional work.

And now we're getting to the point where the basic loop makes sense and we have to stop adding things for a moment and actually measure how well the vision works.

Seeing those steps written down makes the project much easier for me to understand too.

I work in construction during the day. I'm not sitting at a computer watching every piece of PeakLogic develop. Sometimes a lot of work happens between the moments when I come back and really look at it.

This journal gives me a way to see not only what PeakLogic did, but what it learned and why it changed.

I want to keep doing these updates that way.

Not an update every time some code changes.

An update when something important happens that changes how we understand the project.

That might be because something worked.

It might be because something failed.

It might be because the field showed us that one of our assumptions was wrong.

Or it might simply be the moment when something that was complicated finally becomes clear.

I think that is worth keeping because this project is not just becoming a piece of software.

I'm also learning how to build it.

Log in or sign up for Devpost to join the conversation.

posted an update —

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.

posted an update —

Update 1 — From idea to executable evidence loop Why we deliberately built deterministic evidence mechanics before training a model.

Update 2 — Real field media broke our video sampler The 98-second walkthrough bug, why it mattered, how it was repaired and how the regression test protects it.

Update 3 — Evidence must belong to a job Why Trial 001 caused us to introduce JobEvidenceRecord/Session and reject unbound media.

Update 4 — What happens when the AI doesn't know? The failure matrix, UNKNOWN behavior, human escalation and why missing proof can't simply be fabricated later.

Update 5 — The work order proved the problem exists The real documentation requirements in the construction packet and why “proof before concealment” isn't an invented AI use case.

Update 6 — From mechanics to measured vision Where we are now: architecture largely stable; representative classifier/evaluation and AWS execution are the next gate.

Log in or sign up for Devpost to join the conversation.

Submission history