Bridge in practice: typifying 50,000 documents

We ran Bridge against a working set of just over 50,000 documents from a property operator. The pile contained lease contracts, maintenance invoices, email correspondence, building drawings, insurance policies, and a long tail of "miscellaneous." The goal was to see what actually happens when Bridge gets a domain with real noise, not a curated demo set.

First impression: Bridge does what it claims. Within three days the documents were typified, linked to entities (property, tenant, contract) and queryable as a graph. That's substantive work that traditionally takes six months with a data team. But "works" is a complex word, and the detail is where real value sits.

What worked out of the box

Document-type classification was strong. 96 percent of documents were correctly classified as lease contract, invoice, correspondence or insurance policy. The errors were almost always on low-quality scans of receipts or on internal notes that visually resembled contracts. These got an "unresolved" status, not a misclassification, which is the right behavior.

Entity extraction on lease contracts was also strong. Parties, property, lease term, rent and index escalation were correctly identified in 92 percent of cases. The most common failures were on contracts with unusual 1990s formats, and on agreements where "tenant" was a chain of multiple subsidiaries with the relationship not clearly written into the document itself.

Source tracing was clear and reliable. Every extracted entity could be clicked back to the actual sentence in the original document. For audit and later quality checks, that's decisive, and it worked without configuration.

What required tuning

Clause structuring needed work. Bridge captured clauses, but the categorisation was generic. What counts as "liability limitation" varies between organisations, and the standard categorisation was neither wrong nor exactly right. We had to define a local set of clause categories (operations, maintenance, insurance, default, termination) and link them to concrete examples from existing agreements. After three days of tuning, clause structuring sat at 88 percent precision against human review.

Beneficial-ownership relationships needed specific configuration. On agreements where the tenant was part of a corporate group, the relationship had to be structured up manually. Bridge typified correctly that there was a corporate relationship, but how it should be represented as a relation in the graph was an architecture choice the operator had to make.

Invoice allocation against contract maintenance clauses was semi-automatic. Bridge saw that an invoice concerned a specific property, but the link to which contract clause governed the cost split required us to typify the contracts thoroughly first. That wasn't a Bridge problem. It was a logic problem requiring the operator's domain knowledge.

What still needs human judgement

Decisions on index escalation with unusual formulas. Bridge correctly identified that a contract had index escalation with a cap, but when the formula was "K + 2 percent extra every third year if the last escalation was below 3 percent," it gave a draft with a clear caveat. That's the right behavior. An operator has to do the math and confirm.

Judgement on whether a clause is "unusual." Bridge can flag deviations from the firm's standard template, but what's a problematic deviation from a legal perspective is still a lawyer's call. Bridge gives the basis. The human decides.

Disputes over wording where a counterparty has slipped in formulations that are technically within tolerance but practically problematic. This is exactly the kind of judgement that needs experience and shouldn't be automated.

Time and cost

A traditional project to typify a real-estate portfolio of 1500 leases takes 6 to 9 months with a data team and costs 4 to 7 million NOK. Bridge in practice did it in three weeks (including tuning) for a substantially lower amount, because the sprint is productised and doesn't need every customer to fund from scratch.

What Bridge isn't

Bridge isn't a chatbot on top of documents. It doesn't generate answers to questions directly from the document pile. It produces structured data, linked entities and a queryable graph. Question-driven use happens via Sense and ORM on top, not via Bridge alone. That's a deliberate boundary, and a healthy one.

Bridge isn't a standalone solution for data capture. It works as the intake layer in the Optale stack. If you don't plan to use Sense, ORM, Optale Agents and Observatory on top, Bridge is just another data project. If you do, Bridge is the intake ramp that determines the quality of everything that comes after.

Who should consider Bridge

Companies with large existing document data sets that need to become operating ground for AI. Property operators, law firms, financial operators, public sector with case archives. Anyone who can answer yes to "we have data, we want agents to read from it, we require traceability and EU residency" is where Bridge delivers most real effect.

The tool isn't perfect, but it's honest. It delivers what it promises, it's clear about what needs tuning, and it doesn't require the organisation to recruit its own data team to get started. In a market where many similar tools promise much and deliver little, that's reason enough to look closer.