Machine learning · 2025
Workflow Intake
Long document analysis as a queue, not a request.
Document analysis that takes minutes cannot live behind a synchronous request. The platform is built as a queue with a worker: submissions enqueue, a scheduled worker processes them against search and language-model services, job state persists with attempt counters, and transient failures re-queue with a visibility delay instead of failing the user.
- Status
- Production
- Domain
- Applied LLM · Cloud architecture
- Role
- Architecture, full stack
- Year
- 2025
Stack
- Azure Functions
- Cognitive Search
- Azure OpenAI
- Queue + Table Storage
- Vanilla JS
A two-application intake platform that runs lease and tender documents through retrieval and language-model analysis, producing populated spreadsheet and document artifacts with reviewer confidence signals.
Queue and timer, never synchronous
The architecture is deliberately not request-response.
Jobs enter a storage queue, a timer-triggered worker drains it, and state lives in table storage with per-job attempt counters. A transient upstream failure re-queues the message rather than deleting it, so a rate limit costs latency instead of a lost job.
Confidence made visible in the artifact
Cells the language model populated are tinted differently from template defaults in the delivered spreadsheet.
It is a one-line rendering rule that changes the reviewer’s job entirely: instead of re-checking the whole document, they check exactly what the model asserted. Uncertainty rendered, not hidden.
No build step on the front end
The interface is plain HTML, CSS and JavaScript with libraries loaded directly — no bundler, no transpiler, no lockfile drift.
Pending jobs persist to local storage so they survive a refresh while the queue works.
Showing the chunking, not just the answer
The tender flow surfaces the sections the model actually read alongside its output, so a reviewer can see whether the relevant clause was in the context at all.
Most wrong answers from a retrieval system are retrieval failures rather than reasoning failures, and making the retrieved set visible turns an unexplainable answer into a diagnosable one.
Idempotency is the whole safety property
A queue that re-delivers is only safe if processing the same message twice is harmless.
Job state carries the attempt count and the completion marker, so a worker that dies after doing the work but before acknowledging it does not produce a second artifact. Designing for at-least-once delivery rather than pretending it is exactly-once is what keeps the retry policy from becoming a duplication policy.
Pipeline
Queue, not request
Stage Can reject
-
01
Submit
Job enqueued
-
02
Timer worker
Claimed job
Never synchronous
-
03
Search
Retrieved sections
-
04
Extract
Field values
-
05
Retry gate
Re-queued or done
Transient failure costs latency
-
06
Artifact
Tinted workbook
Model-filled cells marked
Skills exercised
What the build
actually demanded.
Against the corpus · 15 systems
This system Corpus median
Cloud architecture
- Queue-and-worker design for minute-scale jobs
- Durable job state with attempt accounting
- Transient-failure re-queue with visibility delay
- Directory-based authentication on a static front end
Applied LLM
- Retrieval over indexed contract and tender corpora
- Structured field extraction into template artifacts
- Chunk verification surfaced to the reviewer
- Confidence signalling inside the delivered document
What it establishes
-
Queue + timer worker
Minute-scale jobs never block a request
-
Confidence tinting
Model-filled cells visually distinct from defaults
-
Re-queue on transient failure
Rate limits cost latency, not jobs
-
Retrieved context shown
Retrieval failures become diagnosable
-
Idempotent processing
At-least-once delivery handled, not assumed away