FlowLens Drift

FlowLens Drift compares written procedures with real-world work, verifies the evidence, and asks the follow-up question most likely to change the assessment.

Comment

Inspiration

Written procedures describe how work is supposed to happen, but real operations gradually develop shortcuts, exceptions, manual workarounds, and missing records.

These differences are often discovered only after delays, complaints, audits, or incidents. Even then, an organization may know that something is wrong without knowing exactly where the process changed, what evidence supports the concern, or what question should be asked next.

FlowLens Drift was created to make that gap visible without pretending that AI already knows the full truth.

What it does

FlowLens Drift compares two descriptions:

  • Written process: the intended procedure
  • Real work: what people actually do

The MVP then:

  1. Identifies process drift between the two descriptions
  2. Links each finding to checked source lines and quotations
  3. Separates supported evidence from uncertainty
  4. Prioritizes the most important operational gap
  5. Asks one high-leverage follow-up question
  6. Lets a human add missing context
  7. Reassesses the result while keeping the added information visibly unverified

The demonstration uses a fictional invoice-approval workflow.

For example, the written process says approval records are stored with invoices, while the real workflow may use chat messages or personal email addresses without consistently copying those records into the shared finance process.

After the user adds context, FlowLens updates the assessment. It does not automatically treat that answer as verified evidence, and it does not invent a stronger conclusion when the new information does not justify one.

How we built it

FlowLens Drift is a one-page Next.js and TypeScript application.

The analysis flow uses the OpenAI Responses API with GPT-5.6 Terra. Structured Outputs define the expected analysis schema, while application-side validation checks that evidence references match the original source lines and quoted text.

The implementation includes:

  • Next.js server-side API route
  • OpenAI JavaScript SDK
  • Zod schema validation
  • Source-line and quotation verification
  • Input-length and empty-input validation
  • Safe handling of authentication, permission, quota, rate-limit, timeout, connection, parsing, and evidence-validation errors
  • Human-controlled follow-up submission
  • Clear separation between checked evidence and unverified context
  • Vitest automated tests
  • Playwright-based demo capture and visual checks

Codex was used throughout the build to scaffold and refine the application, design the structured schema, implement evidence validation, create tests, troubleshoot the API workflow, and build a reproducible demo-video production and QA system.

Challenges we ran into

The main challenge was not generating a list of plausible problems. It was preventing plausible language from being mistaken for evidence.

We needed to ensure that:

  • cited line numbers actually existed
  • quoted evidence matched the original input
  • unsupported context remained visibly uncertain
  • API failures did not expose secrets or raw responses
  • the follow-up question focused on information that could materially change the assessment
  • reassessment remained honest even when the highest-priority risk did not change

Another challenge was producing a reproducible end-to-end demonstration while preserving the real behavior of the application instead of staging a fake result.

Accomplishments that we're proud of

The finished MVP demonstrates a complete evidence-grounded loop:

compare → identify drift → verify evidence → expose uncertainty → ask one question → receive human context → reassess

The final application passed:

  • 54 automated tests
  • TypeScript type checking
  • production build verification
  • linting with zero errors

Secrets, API responses, generated videos, audio files, and browser traces were excluded from the Git repository.

We are also proud that the updated analysis remained honest. The added context clarified the scale of the issue, but the system did not pretend that the main risk or evidence strength had changed when they had not.

What we learned

AI process analysis becomes more useful when it does not hide uncertainty.

A confident-looking recommendation is not enough. Operational users need to see:

  • what came directly from the source
  • what was inferred
  • what is still unknown
  • what additional information could change the result
  • where human judgment is still required

The most valuable output is sometimes not a recommendation, but the next question that should be answered.

What's next for FlowLens Drift

The current MVP analyzes one written process and one description of real work.

The longer-term direction is to help organizations collect process observations over days, weeks, and months through guided questions and answer support. Repeated issues across roles or teams could then be grouped into reviewable improvement cases.

Humans would still decide:

  • whether an observation becomes a formal case
  • whether additional evidence is required
  • whether an improvement experiment should be approved
  • how the results should affect the organization

FlowLens Drift is intended to improve processes, not evaluate or blame individual employees.

The goal is to move from one-time findings toward continuous, evidence-grounded organizational improvement.

Built With

Share this project:

Updates