Looski · Proposal

A second reviewer for <PROSPECT> that reads every sheet, on your premises.

A proposal to turn your Rule Library into checks that run across every drawing and specification in a set, on hardware you control. Your reviewers and your existing Claude setup keep the judgement. We take the exhaustive reading.

Prepared for <PROSPECT> · September 2026 · Kevin Loo, Looski

How to read this. This is a draft proposal, written before we have seen your files. Where it describes your process, it is our understanding, and we expect you to correct it. Every capability here is a pilot deliverable with an acceptance test (section 8), not a claim. We publish no accuracy or speed figure we have not measured on your documents. Anthropic and Bluebeam facts were checked against their own documentation on 22 September 2026.

Summary#

Your product is a review that finds what the design team and the value engineering list missed. Its value depends on reading everything: every sheet, every detail, every specification section. That is the part of the work that scales with the size of the set, not with your expertise. It is also the part a machine can do without getting tired.

What we propose

One Apple silicon node in your office, operated by Looski, that applies your Rule Library to every sheet and every specification section of a set, and hands your reviewer a list of candidate findings, each tied to a sheet and page.

What stays the same

Your reviewers decide what is a finding. Claude keeps doing what it does well for you: reasoning about a finding and writing it up. Your team keeps working in Revu, Word and Excel on Windows. Nothing is installed on their desktops.

What we do not claim

Open models running locally are not as capable as Claude. Reading construction drawings is hard for every AI system today. We will not tell you how many findings we catch until we have measured it on your own past projects.

What we ask

A pilot that replays two completed projects whose findings you already know, then runs alongside one live review. You set the pass mark. The results are yours.

Your review, as we understand it#

From what you publish, a review runs roughly like this. Tell us where we are wrong; the pilot is scoped around the steps that cost you the most hours.

1A set arrives. Design development drawings for the first pass, the permit or GMP set for the second, with the specification book and the owner’s existing value engineering list.
2Someone reads all of it. Construction type, code pathway, structural approach, system configuration, assemblies, and details carried over from earlier projects that do not fit this one.
3The Rule Library is applied. Your accumulated patterns of design decisions that cost money without adding value, checked against this set.
4Findings are written up. Each with its evidence, page references and an estimated saving, excluding anything already on the value engineering list.
5Redlines and a report go to the owner. Adopted findings are later certified as net savings with the contractor.

Steps 2 and 3 are where a set with hundreds of sheets turns into weeks of expert time. Steps 4 and 5 are where your judgement and your writing are the product. We propose to help with the first pair and leave the second pair to you and to Claude.

Keep Claude. Add a reviewer that reads everything.#

You already have a capable model under a zero-data-retention agreement. We are not proposing to replace it. We propose to take on the part of the work that is exhaustive, repetitive and heavy on documents, which is expensive to push through any hosted model and awkward to keep inside a ZDR boundary.

Task	Claude, under your ZDR	Looski node, in your office
Reading every sheet and specification section against every rule	Possible, but priced per token, and whole sets go through features your ZDR may not cover (section 4).	Yes. This is the main job. A flat monthly cost, so you can run every rule on every set, every time.
Sheet index, cross-references, schedule-to-plan tags, spec-to-drawing conflicts	Possible, one conversation at a time.	Yes. Deterministic checks where the data is in the PDF’s text and linework; a vision model only for what is drawn.
Holding whole drawing sets and your findings history at rest	Not under ZDR. Stored files fall outside it.	Yes. On storage in your office, indexed and searchable.
Your Rule Library as a working, versioned system	Lives in prompts and people’s heads.	Yes. Each rule becomes a check with an owner, a version and a history of what it found.
Reasoning about whether a candidate is really a finding, and writing it up	Yes. Keep using it for this.	Drafts only. Your reviewer decides.
The final call, and the saving you certify	No.	No. That stays with your licensed professionals.

Where your ZDR agreement stops#

ZDR is a strong arrangement, and nothing here suggests your setup is wrong. It is narrower than it is often assumed to be, and the gaps fall exactly where whole drawing sets would go. These points come from Anthropic’s own documentation. Your agreement and your account team are the authority on what applies to you.

The Claude apps are outside it. Anthropic lists the Claude Team and Claude Enterprise product interfaces as not ZDR-eligible, and the Free, Pro and Max plans likewise. ZDR covers the API, and Claude Code used with a commercial API key or through Enterprise with ZDR enabled. A drawing set pasted into the Claude app is kept under your organisation’s retention settings, not under ZDR.
Stored files are outside it. The Files API keeps files until they are deleted or expire. The Batch API keeps jobs for 29 days. Code execution containers keep data for up to 30 days. Anthropic describes using these as stepping outside ZDR for that data.
The newest models require 30-day retention. Claude Fable 5 and 5.1 and Claude Mythos 5 and 5.1 require 30-day retention and are not available under ZDR unless Anthropic expressly authorises it.
Integrations are outside it. Data processed by third-party tools is not covered. Bluebeam’s MCP integration shares prompts, PDF text, markup data and Studio file metadata with whichever AI client you connect. If that client is the Claude app, it runs through an interface ZDR does not cover.
Some retention applies to everyone. Under any arrangement, Anthropic may keep data where the law requires it, and may keep inputs and outputs for up to two years if its automated trust and safety systems flag a session.

Why this matters to a review firm

You hold confidential drawings and pricing from developers who compete with one another, and the architects who drew the sets own copyright in them. Your Rule Library and findings history are the business. Keeping those at rest on hardware you control, and sending Claude only the passage it needs to reason about, is a cleaner line to draw for your clients than any vendor’s retention policy.

What we build#

1Intake. Sets are picked up from your SharePoint or OneDrive, or from a shared drive, by a connector that only ever reaches out and never needs an inbound door into your network.
2A map of the set. Sheet numbers and titles are read from the title blocks and reconciled with the drawing index. Text and linework are taken from the PDF itself; scanned sheets go through Apple’s on-device text recognition.
3Your Rule Library, as checks. We sit with you and turn each rule into a check. Where a rule can be answered from text, schedules or dimensions, the check is ordinary code and gives the same answer every time. Where it needs to understand what is drawn, a vision model reads the sheet in tiles, since no model reads a full-size sheet at useful resolution in one pass.
4Candidate findings, with their evidence. Each candidate names the rule, the sheet and page, and the text or region that triggered it, and is matched against the owner’s value engineering list so duplicates are flagged before anyone spends time on them.
5Back into the tools you use. Candidates arrive as PDF markups that open in Revu, and as a draft findings table for your report. Your reviewer accepts, rejects or rewrites each one. Where you want Claude’s reasoning on a candidate, only that passage is sent.
6It learns from your decisions. Every accept and reject is recorded against the rule that produced it, so you can see which rules earn their keep, and your findings history becomes searchable for the next estimate.

The hardware

One Apple Mac Studio with the M5 Ultra chip, in your office. Apple specifies up to 512GB of unified memory and 1.2 TB/s of memory bandwidth per node, with a 480 W nameplate power rating; Apple has said the 512GB configuration is coming in late October 2026. It runs headless, like a file server. Nothing about it requires your team to use a Mac. We provision it, deliver signed model and software updates, monitor it, hold a spare, and build the workflows with you.

What already exists, and how this differs

Bluebeam’s Smart Review, on the Max plan and in preview, checks sheet health (blank, missing and duplicate sheets, index gaps, missing referenced sheets), gridline coordination, door tags against schedules, and plumbing tags. Bluebeam says it supports imperial units only, works best on floor plans, and processes uploaded PDFs on AWS servers in the UK. It is a useful baseline and we would test against it. Your Rule Library looks for something different: design decisions that cost money without adding value. That is the part no off-the-shelf checker knows.

Controls you can test#

Each control is a pilot deliverable, not a claim. You, or anyone your clients nominate, can run the test. The pilot fails if any test fails.

Control	What you get	How you test it
Finding traceability	Every candidate finding carries the rule and rule version that produced it, the sheet and page, and the exact text or region it is based on.	Pick any twenty candidates at random and trace each back to its source in the set.
Audit trailAUD-001	Every run recorded: who started it, which set, which rules, which model version, and every accept or reject decision, in a tamper-evident log on your storage.	Reconcile a week of activity. Alter a stored record and confirm the change is detected.
No vendor custodyREC-001	Drawing sets, the Rule Library, findings and logs are stored only on hardware you own. Looski holds no copy.	Inventory where every file is written. Confirm no Looski system holds a copy.
Network postureNET-001	Outbound connections only to destinations you approve: your Microsoft 365 tenant, signed updates, and content-free health metrics to Looski.	Capture traffic at your router for the whole pilot. Every flow must be on the approved list.
Pinned, signed modelsMOD-001 / SUP-001	Models change only when you activate a signed update. The previous version is kept, so a past review can be re-run as it was.	Check the running model against its signed manifest. Roll back, then roll forward.
Versioned Rule Library	Every change to a rule is recorded with who made it and why, and every finding says which version produced it.	Change a rule, re-run a set, and compare the two runs finding by finding.

What we do not claim#

Stated early, so you hear them from us first.

Local models are not as capable as Claude. The open models that run on this hardware reason less well than the frontier models you already use. That is why we give them the exhaustive, checkable work and leave the judgement to your reviewers and to Claude.
Reading drawings is hard for every AI system. Public benchmarks built on real construction documents, such as AEC-Bench, test exactly the tasks in this proposal: cross-references, sheet index consistency, spec-to-drawing sync. They exist because these tasks are not solved. We measure on your sets before we promise anything.
It does not replace your reviewers. Candidate findings are prompts for an expert, not conclusions. A missed finding is still possible, and the professional responsibility for the review stays with your firm.
We make no claim about savings or RFIs. We will not tell your clients that this finds more savings or reduces RFIs by any amount. If the pilot measures an improvement, you decide whether and how to say so.
It is not cheaper per page than a hosted API for light use. If you only ever ran a handful of questions, a hosted model would cost less. The case rests on running every rule on every set, and on where the files live.
It does not work inside Revu. We deliver markups Revu opens, not a Revu plug-in. Driving Revu directly through Bluebeam’s MCP integration from our node is something we would test in the pilot, not something we promise.
The hardware has gaps, and we carry them. Apple silicon does not report memory errors, so model files are checksummed at load and re-verified on a schedule. Apple’s enterprise support is thinner than a server vendor’s, so the spare and repairs are our responsibility, not yours.

The pilot#

You already have something most AI pilots lack: completed reviews whose findings were checked against outcomes. We use them as the answer key.

1Choose the answer key. Two completed projects, ideally one design development pass and one GMP pass, with the sets, the value engineering lists and your final findings. We agree in writing which of your findings a machine could reasonably be expected to spot, and which rely on judgement it cannot have.
2Encode the rules. We work through your Rule Library with you and turn the rules those projects exercised into checks. You own the result.
3Replay, blind. The system runs on both sets without seeing your findings. We report how many of your findings it surfaced, how many candidates your reviewer had to reject, and how long a reviewer took to work through them.
4Run one live review alongside your team. Your team reviews as normal. The system runs in parallel. Afterwards we compare, including anything it raised that your team adopted.
5Decide on your numbers. You set the pass marks before the replay starts: the share of findings surfaced, the rejection rate you will tolerate, and the reviewer time saved. Every control in section 6 is tested too. The results are yours to keep.

Commercial terms#

$2,100 a month, including one operated node, updates, monitoring, a spare, and workflow development.
$700 a month for each additional node, if volume ever calls for one.
If you would rather own the hardware, you can buy it from us at 15% over Apple’s list price.
Pilot scope and fee to be agreed in writing before it starts.

Your Claude subscription or API spend is separate and stays with Anthropic.

What we need to learn from you#

The answers change the scope, so we would rather ask than assume.

Which Claude products do you use today: the Claude app, the API, Claude Code, or several? Which models? Do whole sets ever go in as uploaded files?
Do any of your clients’ NDAs or contracts limit which outside services may process their drawings or pricing?
Where do the hours go on a typical review, from receiving the set to sending the report?
What form is the Rule Library in today, roughly how many rules, and how are findings and outcomes recorded?
Which Bluebeam plan and version do you run, and where are project files kept: SharePoint, OneDrive, or a shared drive?
How many reviews a year, how many sheets in a typical set, and what would you do with more capacity?
Do architects ever give you models (IFC or Revit), or only PDFs?

Sources#

Anthropic, Bluebeam and Nomic sources checked on 22 September 2026; Apple sources on 21 September 2026.