TheoFlow

At a Glance

The Challenge

Document-heavy industries like insurance run on paper forms and submitted documents that still need to become structured, validated data: policy applications, claims, onboarding paperwork. Doing that by hand is slow and error-prone. Doing it with a single-purpose OCR tool solves extraction but leaves the surrounding workflow (publishing the form, collecting responses, validating them, getting a signature, producing a sealed record) as separate, disconnected steps.

The harder problem sits underneath: any platform built to serve multiple clients across multiple document types cannot know in advance what a new tenant will submit. A system built around per-client templates breaks the moment a new form type shows up. It needs to work the same way on the first document from a new tenant as it does on the thousandth from an existing one.

The Inspiration

TheoFlow was built under the THEODORE brand in partnership with Chuma Memela of Genie-yus AI, structured from the outset as a platform, not a single-client tool. That decision shaped everything downstream: rather than building bespoke extraction logic per client or per form, the platform is built around one general-purpose, template-free pipeline that treats every document from every tenant the same way, new or recurring.

That conviction, that reliability should come from technique rather than from foreknowledge of what any given client will send, is the core design bet behind TheoFlow. It trades the short-term convenience of a client-specific template for a platform that doesn't need to be re-engineered every time a new tenant or new form type arrives.

This section covers the design philosophy behind the build. If there's a more personal catalyst, a specific problem witnessed, a conversation, a prior project that exposed the gap, worth naming, it's worth adding here.

The Approach

TheoFlow is organised into six named products, each covering a stage of the document lifecycle:

Reliability is engineered in rather than assumed. Every document that passes through Forge goes through a self-consistency double-pass reconciliation, confidence-based routing to human review where extraction is ambiguous, and tiered model routing (Claude Haiku, Sonnet, or Opus) based on a computed complexity and risk score, escalating to the strongest model only when the document actually warrants it. That keeps cost proportionate to difficulty instead of running every document through the most expensive model by default.

Technical Architecture

Forge, the extraction engine at the centre of the platform, runs as a six-stage pipeline:

1. OCR via asynchronous Amazon Textract (FORMS and TABLES), routed through a staging bucket to reach a Textract endpoint
2. Structuring, computing block-level confidence scores and flagging handwriting
3. Document intelligence scoring, computing complexity and risk scores that route the document to the appropriate model tier, escalating to the strongest tier when risk or complexity crosses a set threshold
4. Field inference, reconstructing field labels from key-value blocks, classifying them, and flagging ambiguous fields for review
5. LLM resolution, invoked only on the fields flagged ambiguous, with the model tier downgrading as confidence allows
6. Validation, checking field types and duplicate keys, routing failures to a dead-letter queue for retry

Schema storage is designed for safe iteration: every schema change is stored as an immutable, versioned record, with a separate pointer tracking the latest version against the version actually published and in use, so a form in production is never affected by changes still being drafted.

The platform is built on 11 Lambda functions, managed as infrastructure-as-code with Terraform, with the codebase organised in GitHub using submodules.

Navigating a Regulatory Constraint

Amazon Textract, and later Amazon Bedrock Data Automation, are not available in the af-south-1 (Cape Town) region. Rather than default to a region where the service is available without examining the consequences, this was treated as a compliance question first: routing documents through a staging bucket in eu-west-1 constitutes a cross-border transfer of personal information, which under South Africa's POPIA (Section 72) carries its own obligations. The architecture accounts for that transfer explicitly rather than treating it as an implementation detail, which matters for any platform intended to operate in a regulated industry.

Status

Channel and Harvest are live. Decode has been verified end-to-end against 35 fields with zero validation errors. Print is deployed but not yet in active use. Sign is fully designed and awaiting implementation. Daai Insure is running as the platform's live MVP client, with its requirements already mapped across the relevant Forge Lambda functions.

What This Demonstrates

• Platform-first thinking: a multi-tenant architecture designed from day one to generalise across clients and document types, not retrofitted after a single-client build
• Regulatory-aware cloud architecture: a genuine cross-border data transfer constraint identified and addressed at the design stage, not discovered in production
• Cost-conscious use of large language models: tiered routing that reserves the most expensive reasoning for the documents that actually need it
• A working partnership model: a 50/50 revenue-share build with an external AI partner, structured around use-case-based pricing

TheoFlow is one example of the applied AI and cloud architecture work behind ByTheodore's AI implementation and cloud engineering services.