How we install automated workflows

In 1978, a Harvard Business School student named Dan Bricklin watched a professor work through a financial model on a blackboard. Every time one assumption changed, the professor had to erase and rework every number that depended on it, by hand. The next year, Bricklin released a program called VisiCalc. The same grid, on a screen, where the numbers updated themselves. The clever part wasn’t what it changed. It was what it kept. The grid on the screen was the accountant’s paper worksheet, column for column. Even the name was borrowed, a “spreadsheet” was paper long before it was software. There was almost nothing to learn, so it spread. The erasing and reworking vanished; the worksheet survived.

Nearly fifty years later, that worksheet is your Excel model, and it is still the center of how your shop works. But the work around the model never got the same upgrade. The reports built on top of it, the monthly close, the quarterly reforecast, the partner package, the diligence memo, are still rebuilt the way the professor worked his blackboard: by hand, line by line, every period. We install automated workflows for Canadian real estate operators that handle that assembly, and they follow the spreadsheet’s rule: your model, your template, and your conventions stay exactly as they are. The assembly runs itself, and your team’s month goes to what the numbers mean.

Download as PDF

The rules

Five rules govern every installation.

  1. Your model, your template, and your conventions stay exactly as they are.
  2. The AI never writes a number and never touches a formula.
  3. Everything is built as if the AI is wrong, so a mistake cannot survive.
  4. Nothing runs forward until it has reproduced your own past packages and your reviewer has signed off.
  5. You own everything we build, and one of your people runs it after handover.

How a workflow runs

Runs on your systems Rent roll unit 204, $2,150 AI reads it tags what, where Your model your math runs Failed check holds the run AI drafts words never the numbers The package the number, cited Runs on your systems Rent roll unit 204, $2,150 AI reads it tags what, where Your model your math runs AI drafts words never the numbers Failed check holds the run The package the number, cited
✓ marks an exact comparison at that move Only the AI’s reading and drafting reach outside your systems.

The machine has three parts with three jobs. The AI reads documents and drafts words. Code moves numbers. Your model computes them. The AI never writes a number, never touches a formula, and nothing it drafts goes out unchecked.

Here is one number making the trip. A rent roll arrives, and line 40 says unit 204 paid $2,150 in May. The AI reads the page and tags the number with what it is and where it sits: unit 204, May, base rent, page three. That is the one step that takes interpretation, because every document is laid out differently. Everything after it moves by rule.

Code places the $2,150 into the cell of your model where May rent for unit 204 belongs. The map between labels and cells is set during installation. Your model runs your formulas. Code reads the result out of a named cell and locks it into the package, so the number in the writeup is the number in the cell. The AI drafts the commentary around those numbers. It never writes them.

The workflow runs on your systems. Nothing leaves them except what the AI needs to read a document or draft the commentary, and each request sends only that.

Built so a mistake cannot survive

Every AI company will tell you its model is accurate. We build as if it is not. The machine assumes the AI can misread, and is designed so a misread cannot survive the trip.

Every move that number makes is checked, in three layers, each built for a different way things go wrong.

Layer one catches a number changing in transit. Code runs an exact comparison at every move: the $2,150 placed in your model equals the $2,150 that was read; the figure shown in the package equals the model cell it’s locked to; and a figure that appears in two places, in two documents, or in one model feeding another, has to match everywhere it appears.

Layer two catches a misread. Reading is the only step where the machine can be wrong in a way that looks right, so it gets three checks, one for each way a read goes wrong. Every document is read twice, and the two reads must match; a random slip does not repeat itself. A consistent misread would repeat, so the document is held to its own arithmetic: where a page prints its total, the line items have to add up to it, and a wrong column or a missed row breaks the total. And none of it is taken on faith: during installation, we check a sample of your documents by hand against the source. The AI does the reading; code does the comparing.

Layer three catches the words outrunning the numbers. Before the package goes out, the commentary is checked against the figures it describes. Meaning can’t be compared by rule, so this check is the AI’s own, and that makes it the machine’s softest layer. It sits alongside your review, not instead of it. What it catches is drift: words that claim more than the numbers show, or credit a change to a driver they don’t back.

Any check that fails stops the run and names the line. If the rent roll shows $1,895 for unit 310 and the ledger export shows $1,850, the run holds, with the unit, both figures, and both documents named, until someone resolves it. Every package goes out with its verification beside it: every figure tied to its source, or flagged with the reason.

Two ways the model fits

Where the model comes from depends on the work.

For recurring work, the monthly close, the quarterly reforecast, the partner package, the model already exists: it’s yours, and it stays the authority. The workflow feeds figures in and reads results out.

Diligence is different. Even when your underwriting template is standing, the model for a given target starts empty and gets filled fresh, and fresh inputs mean assumptions. Assumptions are where diligence goes wrong quietly. So the workflow keeps a ledger of them: every input that wasn’t pulled from a source document is listed as an assumption, with the value and the reasoning beside it. On the page, not buried in a cell. Where no template exists for the work, the model gets built during the engagement, and it’s yours when it ends.

The acceptance test

All of the above describes the machine. Before it earns a place in your shop, your reviewer puts it through an exam. During installation, the workflow reproduces the assembly behind packages your team has already produced, and the reviewer grades the result against the original. Every difference is listed and resolved. Defects get fixed, and house standards get built in: how things are presented, what gets shown. A correction made once never has to be made again. The machine reproduces the assembly in those packages, never the judgment. The judgment stays your reviewer’s, in every package after. The workflow runs forward when your reviewer says so.

That much fitting is deliberate. When MIT researchers asked in 2025 why the great majority of corporate AI pilots fail, 95 percent by their count, the answer wasn’t model quality. It was fit: tools that never adapted to how the shop actually works. The industry keeps failing on the two things this machine is built around. Assume the AI is wrong, and fit the tool to the shop instead of the shop to the tool.

The first installation

In 2025, a senior buy-side reviewer engaged the studio to install a diligence workflow for publicly traded REITs, the diligence mode described above. He was both the client and the reviewer, so the output was graded against his own standards. The engagement ran six weeks, and the first run produced full diligence on a REIT he was evaluating.

Every property in the portfolio is modeled individually. Third-party appraisals stay in their original form, adjustments beside them in their own columns, the reasoning for every change written next to it. Forward projections are built two ways, one anchored to actuals, one to management guidance, with a row at the top comparing them, so the gap between the company’s story and its record is the first thing the reviewer sees.

Underneath it, every figure is traced. Public filings, appraisal data, broker reports, and his own research pulled into a single organized library, each figure tagged to its source document and page. The memo is assembled to his conventions, calibrated during installation against samples of his past diligence work, with every claim in the prose citing a specific model cell. He reads the memo with the Excel open beside it and audits any number in seconds.

The first package cleared institutional review. The workflow stayed installed and runs on each subsequent REIT without rebuilding. A monthly close is the simpler installation: standing model, known sources, and the same template every period.

What you own

Everything built during the engagement is yours: the workflow, the label-to-cell maps, the checks, and in diligence mode the model itself.

The AI inside the workflow is rented, deliberately. Models get better every year, and when a better one arrives, it is swapped in and proven before it is trusted: the workflow re-runs a package it has already produced, and every difference between the two runs has to be explained. A swap, not a rebuild. It is also why “which model do you use” is the wrong question. The model is the rented part; the checks, the maps, and the calibration are what the output stands on, and those are yours. Every model release for the rest of the decade makes the same installed workflow better.

Owning it means running it, so handover is to a person, not a manual. Early in the installation, one of your team is identified as the workflow’s owner, your AI champion, and works alongside the build. By handover they can run it, check its verification, maintain the maps as your accounts change, and make the model swaps as they come. The engagement is built to end; the workflow, and the person who runs it, are already yours.

Background

Ethan Farrar
Ethan Farrar · Founder

Provenance Studio was founded by Ethan Farrar in 2022. He built the first version of what runs these installations that year and has spent the four years since bringing its output to the standard the work requires. The path ran through finance and engineering. Before ChatGPT’s public release, he built re.search, a browser extension that generated an AI summary for any search, an early version of what is now standard in Google. He tested whether LBO modeling could be automated inside an investment bank, and built visualization and performance-reporting workflows for the research, sales, and finance teams at a hedge fund. By 2025, the technology had matured enough to produce serious analytical work, provided the right discipline was built into the workflow. Provenance is the result.

Next steps

Engagements start with a conversation. No cost, 30 to 45 minutes. Bring the package that takes the most of your team’s month. If the fit is there, the next step is a scoping sprint, also at no cost: two to three weeks inside how your shop works, ending in a written plan and a firm price for the installation.

Book a free scoping call

Reach us at ethan@provenancestudio.ca.