AI In Operational Workflows

Summary

AI and OCR are useful in LKCI because many workflows are evidence-heavy: documents, portal files, emails, estimates, POA packages, precon plans, sizing signals, RFI drafts, and operational summaries. The architectural rule is that model output is evidence, not authority. It may accelerate interpretation, but it should not silently decide business state.

That rule is not a slogan. It determines where model calls live, what gets logged, how structured output is parsed, how confidence and citations travel, when humans review results, and which state transitions are allowed. The platform can use AI aggressively where it improves evidence extraction and drafting while staying conservative about side effects.

Module At A Glance

Start With The Review Surface

An operator rarely needs a raw model transcript. They need to know what the system believes, where that belief came from, how confident it is, what source artifact supports it, and what correction is available. In POA, that may mean interpreted document fields and a repairable command decision. In precon, it may mean sizing evidence, document classification, or RFI draft language. In a morning brief, it may mean validated summary text. The UI should present model-assisted output as inspectable evidence inside a domain workflow.

Working backward from that surface gives the right architecture. OCR and LLM services provide capabilities. Domain services prepare context, call those capabilities, parse structured results, validate business rules, and decide whether output can become accepted evidence. Review surfaces expose uncertainty and correction. Jobs may orchestrate expensive work, but they should not hide business judgment inside a model call.

Evidence, Not Authority

The difference between evidence and authority is clearest at the state transition. A model can suggest that a POA document implies a certain vendor, amount, or action. It cannot by itself decide that an external sync is safe. A model can propose a precon sizing signal. It cannot by itself make a final business commitment. A model can draft an RFI. It cannot by itself send it as human-authored communication. Domain services and operators own those transitions.

This posture protects the platform from two failure modes. The first is over-automation: a probabilistic result mutates operational state before anyone can inspect it. The second is useless caution: model output is generated but never connected to workflow state, so it becomes an isolated note. The platform wants the middle path. Model output should be structured enough to be useful and governed enough to be safe.

The state-machine visual makes that path explicit: source artifact, OCR, prompt/runtime context, model output, parse, validation, review, accepted evidence, correction. A result is not operationally meaningful until it passes through that chain.

Prompt And OCR Boundary

OCR, prompting, parsing, validation, and domain judgment are separate responsibilities. OCR turns an artifact into text, layout, or extracted evidence. Prompting turns prepared context into model output. Parsing converts that output into typed structures. Validation checks shape, citations, required fields, confidence, and domain rules. Domain workflow state decides what happens next.

Keeping those steps separate makes failures diagnosable. A poor OCR result is not the same as a weak prompt. A malformed JSON response is not the same as a valid response that fails a business rule. A correct extraction may still be insufficient to execute a provider command. If all of this is hidden behind one helper, support has no way to know what to repair.

Prompt versions, model configuration, input fingerprints, source references, and parser behavior should be retained where the result can influence later work. That does not mean every exploratory model call becomes a permanent case artifact. It means operational evidence needs enough provenance to answer why the system believed something at the time.

Domain Examples

POA is a high-stakes example because interpretation can lead to external sync. The model-assisted part can extract or propose structured evidence, but POA services must decide whether the package is complete, whether ambiguity creates an issue, and whether a command is safe to dispatch. A correction should become workflow state, not a comment buried in logs.

Precon has a different shape. Documents arrive from solicitations, portals, attachments, and internal review. OCR and LLMs can classify files, extract sizing signals, summarize plan context, and draft candidate RFI text. The operator still needs evidence, citations, and editable outputs because precon decisions depend on judgment, not only extraction.

Marketing and communications add another boundary. A model may help render or draft content, but delivery requires campaign policy, suppression, review, and recipient context. The model does not own who may be contacted or when a message leaves the platform.

Correction Loop

Human correction is not a last-mile UI feature. It is part of the model lifecycle. When an operator fixes a classification, rejects a sizing signal, edits draft language, or resolves an interpretation issue, that correction explains both the current workflow and the model's failure mode. The platform should preserve it in the domain state where it matters.

This correction loop supports improvement without making the model a hidden authority. Accepted and rejected evidence can guide prompt changes, validators, tests, review affordances, and future automation thresholds. The platform can become more automated over time because it records where judgment was needed.

The loop should remain domain-specific. POA repair, precon sizing review, RFI editing, marketing asset approval, and morning brief validation do not need a generic "AI review" table to mean the same thing. They need a shared posture: source evidence, generated output, validation, review, correction, and auditable acceptance.

Where To Be Conservative

Be most conservative where generated output could cause external side effects or irreversible commitments. Provider syncs, customer communication, payroll repair, POA commands, campaign delivery, and precon decisions should all pass through deterministic validation and domain-owned state. Inline model calls in routes or jobs are especially risky when their result immediately mutates business state.

Be more experimental where the output is advisory, reviewable, and clearly bounded: candidate summaries, search assistance, document triage, draft text, evidence clustering, or operator-facing explanations. Even there, the output should carry source context so a person can judge it.

Testing The Boundary

AI tests should protect contracts, not model cleverness. Useful tests check JSON sanitation, parser behavior, required fields, citation handling, prompt version selection, fallback behavior, review issue creation, and the rule that domain state changes only after validation. A test that merely asserts a mock model was called is weaker than a test that proves malformed output becomes a repairable result.

This testing posture is what makes provider and model changes possible. The platform should be able to change OCR engines, model vendors, prompt versions, or structured-output helpers without rewriting POA, precon, marketing, or notification workflows. Domain tests should care about internal evidence contracts and accepted state transitions, not the exact external response shape.

The same posture is important for future agents. An agent can summarize, recommend, or request action, but the durable contract should remain evidence, validation, available action, approval when needed, and audited state change. That keeps agentic behavior inside the same operating model as humans and jobs, which is the only way it remains supportable in real operations. The boundary should stay boring operationally.

Implementation Boundaries

services/llm and services/ocr own reusable capabilities: model calls, structured output handling, prompt/runtime context, OCR behavior, and audit support. Domain packages such as services/poa/interpretation and services/precon/sizing own business interpretation. Tests under tests/llm and domain tests protect parsing, sanitation, structured-output contracts, and fallback behavior.

The invariant is that model providers are replaceable and generated output is reviewable. The rest of the platform should consume internal contracts, not a vendor response shape.

Visual

The AI/OCR state-machine diagram is the visual guide for this post. Read it as a safety rail: source artifact, OCR, prompt version, model output, typed parse, validation, review, accepted evidence, correction. If a workflow skips from "model output" directly to "side effect," it has bypassed the platform posture.

Source Evidence

  • services/llm
  • services/ocr
  • services/poa/interpretation
  • services/precon/sizing
  • tests/llm