Current App
Architecture & AI
A speaking brief for explaining the working prototype, with the technical detail one click away.
What runs where
Explore the architecture & sequence diagrams Inspect components or step through uploads, voice, assistant actions and PDF export.| Part | Current technology | Why it is there |
|---|---|---|
| Interface | Plain JavaScript, HTML and CSS | One responsive app for capture and reporting. |
| Backend | Python, Django, Django REST Framework | Authentication, workflow rules and saved data. |
| Storage | SQLite + private filesystem volume | Relational records and original media for this single-server demo. |
| AI | OpenAI APIs + OpenAI Agents SDK | Extraction, transcription and controlled application tools. |
| Export / hosting | Playwright/Chromium; Docker, nginx, Coolify | Render frozen report snapshots and deploy the application. |
Implementation: Storage settings ↗ · Processes ↗ · Container ↗
Three distinct AI paths
From document to report fields
The worker sends the PDF or document image to OpenAI with a schema of allowed fields. The model is instructed to return null for missing or uncertain values. Python validates the response before applying it.
Autofill is cautious: only blank, unchanged fields without prior human edits are automatically filled. Other extracted values remain alternative suggestions. The saved value links to the original document and processing job.
Traceability is document-level. The current extractor does not produce the exact highlighted page regions shown in the separate evidence-graph concept.
Walk through the fixed steps
The application chooses the route. Only the marked stages use AI.
What if the result takes a different branch?
From spoken observation to structured information
OpenAI first turns recorded audio into text. A second model call extracts allowed observation details from that transcript. The app retains the original audio, transcript and processing metadata, and checks revisions before applying changes.
Measurements must come from explicit source statements. This is structuring the professional’s observations; it is not independent diagnosis from a photograph.
The chat microphone is different: it inserts editable text into the message composer. It does not automatically send the message or create report evidence.
Walk through the fixed steps
The application chooses the route. Only the marked stages use AI.
A model using a defined set of app actions
The OpenAI Agents SDK runs a bounded conversation loop. The assistant can find permitted reports, read saved fields, identify gaps, inspect evidence and job status, request field changes and start a fixed draft export. It receives tool results rather than unrestricted database access.
The server is the gatekeeper: tools check user access, field types, report selection and revisions. Runs and receipts are stored so progress can survive an interrupted request. The model is instructed to claim success only after a completed receipt.
Current deployment default: requested field changes can save immediately. Professional-only values still have additional restrictions. Document requests keep their review step, and report generation requires an explicit export request.
See where the model chooses the next action
The model chooses tools; application code controls access and execution.
Questions you may get
Short answers you can say aloud. Expand only what you need.
Is it a chatbot, an agent, or an AI pipeline?
All three interaction patterns exist, but they do different jobs. Document and audio processing follow fixed pipelines. The chat assistant uses an agent loop to choose from defined application tools.
Which models are you using?
The adapter defaults and deployment guide name gpt-5.6-luna for extraction and the assistant, and gpt-transcribe for audio. These are configuration choices, not hardwired architecture. The live environment can override them; this brief does not independently audit the running model settings.
Did you train a model? Is this RAG?
There is no custom training or fine-tuning pipeline in this implementation. The extraction path supplies documents directly to the model. The assistant retrieves saved information through application tools; there is no vector database or embedding-based retrieval pipeline in the inspected path.
Can the AI overwrite what an engineer entered?
Automatic document extraction preserves human edits and retains alternatives. An assistant edit explicitly requested through chat is a different path: deployment defaults allow direct changes after access, type and revision checks. Do not describe every AI change as requiring an approval card.
How do you prevent hallucinations?
The app limits extraction to allowed fields, validates structured output, retains originals and checks writes on the server. The assistant is instructed to use saved records and tool results. These controls reduce risk; they do not prove that every extracted value or generated answer is correct. The professional still reviews the report.
Is the AI making engineering decisions?
The AI assists with captured information and report tasks. It is instructed not to infer eligibility, inspection state, damage severity or professional conclusions. Certain workflow fields require explicit professional input. A generated report remains a draft, not professional sign-off.
Does it work offline?
The browser has an IndexedDB outbox and a service worker for prepared offline capture. Unsynced work stays on the device until it can sync. Cloud AI, server-side exports and the assistant need a connection; the assistant reads saved server state, not unsynced local changes.
What leaves our server?
For AI processing, the relevant document or audio is sent to OpenAI. The assistant also sends conversation context and tool results to its model. API credentials remain server-side. Responses calls set store:false and SDK tracing is disabled; that is not a blanket claim about provider retention or compliance.
How is the final PDF made?
Application code freezes a saved report version, assembles HTML and renders it with Chromium through Playwright. The PDF layout and numbering are produced by code, not invented by the model. Later edits create a new version rather than rewriting the earlier snapshot.
Is the evidence graph already built?
The graph you saw is a separate illustration. The working app has evidence IDs, source-linked fields, suggestions, revisions and report snapshots. It does not yet have the general reusable claims → verified facts → many reports knowledge layer or precise document-region citations.
What is MCP doing here?
MCP is an optional authenticated entry point to the same application tool registry, for an external assistant client. It needs OAuth and an explicitly linked user identity. Its implementation is present; this brief does not claim a live ChatGPT connection has been tested.
Could this scale into a product?
This is a single-server prototype with SQLite and persistent files. The application already separates the browser, business rules, workers and AI adapter. Production scale would require measured work on storage, concurrency and operations; it is not demonstrated by this demo.
What this briefing establishes
Based on source code at 0c62489 and checked-in deployment defaults, inspected on 14 September 2026. It explains implemented behaviour; it is not a fresh production-runtime, security or load-test audit.
Further evidence: Python dependencies ↗ · Browser storage ↗ · Frozen report versions ↗ · PDF renderer ↗ · Deployment guide ↗