Gurpreet Singh
Panesar

The problem

An engineering firm receives project documents through three channels — physical scans, email attachments, and direct uploads. Every document had to be opened, identified, and manually filed to the correct project folder on their server. Staff time went to filing rather than engineering, and misfiled documents surfaced weeks later during project reviews.

The constraint that shaped the design

The documents are confidential architectural drawings. Sending them to a cloud AI API was not acceptable to the client, which ruled out the obvious approach. Everything had to run on the client's own infrastructure.

What I built

A Go service that ingests documents from all three channels, reads them with a locally hosted vision-language model, extracts the project number and civic address, and files them automatically to the correct location on the firm's SMB server.

• Local inference layer. Ollama running Qwen2.5-VL on-premise. I specified and deployed the supporting GPU hardware for continuous 24/7 operation.
• Extraction reliability. Local vision models hallucinate on handwritten markups and bleed context across pages in multi-page sets. Resolving this — rather than accepting first-pass output — was the majority of the engineering effort and the difference between a demo and a production system.
• Email ingestion. Gmail pipeline with cross-mailbox deduplication using RFC 5322 message IDs and SHA-256 content hashing, so a document sent to three people in the firm files once, not three times.
• Input surfaces. A PySide6 desktop scanning application and a web upload portal, so office staff feed the pipeline without touching the backend.
• Filing logic. Built around Canadian and BC-specific civic addressing conventions, which are inconsistent enough that naive string matching fails.

The problem

Structural drawings communicate frame assemblies as tag numbers — a wall, post, or hold-down is labelled, and the actual specification lives in a schedule table elsewhere in the drawing set. To understand what a single frame is, a crew member cross-references the tag against the schedule and mentally assembles the result. That took around 20 minutes per frame, and it is exactly the kind of interpretive work where errors turn into rework on site.

The hard part

Real-world drawing sets put every floor in a single AutoCAD Model Space. There is no structural separation between floor one and floor three — they are geometry in the same coordinate space, distinguished only by convention. Any tool that wants per-floor data has to work out where one floor ends and the next begins.

I solved this by detecting viewport boundaries to isolate each floor region, then aligning the isolated regions against the drawing's structural grid lines so members can be referenced consistently across floors.

What I built

A Python pipeline built on ezdxf that reads DXF drawings and:

• Extracts per-floor frame geometry automatically, removing manual takeoff from the workflow.
• Parses member tags and schedule tables into a structured data model.
• Resolves wall, post, and hold-down callouts to their assembly definitions.
• Feeds an interactive viewer where the crew selects a member and sees the frame design render immediately.

The problem

A client running legacy analog phone lines had no record of customer calls beyond whatever people wrote down afterwards. Commercial call-recording products assume VoIP infrastructure they did not have, and off-the-shelf transcription handled only English — their calls are multilingual.

What I built

An end-to-end recording and summarization pipeline on commodity hardware.

• Telephony layer. Asterisk on a Raspberry Pi, bridging analog lines into a software-controllable system. A custom Python application drives call handling through the Asterisk REST Interface rather than dialplan scripting.
• Multi-device routing. Asterisk PJSIP configured for simultaneous ringing across devices, with WebRTC support.
• Transcription. Gemini API for speech-to-text across multiple languages — the capability that off-the-shelf tools could not provide.
• Summarization. Ollama running Gemma 3 locally, condensing long call transcripts into structured summaries. Kept local so conversation content stays on the client's premises.