Meet Notes 2026-10-14-jdu-ifee-mes

Today's notes are on a new page

Today (Oct 15) has its own page: open today's notes. New replies, the proposed document list and today's questions are there.

Handoff: pick up here

Paused for a meeting. Picking up in about 30–45 minutes. Start here.

Where we are, in one line

Experiment 1 is designed. What's left is who builds the single-document path, the exact documents, and a few small calls.

Decided today

• What's tested: flow 0 (taking a document in and working out what it is) and flow 1 (filling the inventory from a closed deal), plus matching each document to the right deal.
• Flow 0 doesn't care where a document comes from (Reid). It starts from a file wherever it sits: an email inbox, the SharePoint inbox, or a deal folder. Each entry point gets connected later.
• The test: 25–30 documents across all 8 types. Take a document out of a deal we already have answers for, give the raw document to the system, and see if it fills the answers back in. This works on any document type.
• Build first: a proper way to send one document through. No workaround.
• Records: a new table in our existing database. Facts are pulled out before matching to a deal.
• Safety: it matches alone only when it can point to proof. Unsure documents go by internal email. A person checking a match sees the page image, the quoted words, and which deal and why.
• Measured: how good each step is, and whether it runs end to end with very little supervision. The key number is how often it was wrong and didn't ask.

What we found

• The documents exist: 76 division orders in 33 deals, 13 check stubs, and plenty of deeds, leases and letters.
• Division orders can be checked against the decimal interests already in our answers. Check stubs can be checked against Reid's revenue data.
• Tax statements: only 3 deals have them.

Pick up here: 7 quick questions, not answered yet

On the Discussion page, under "Before experiment 1 can run":

1. Who builds the single-document path?
2. By when?
3. Should Claude propose the exact 25–30 documents now?
4. Tax statements: get more, drop them, or use the 3 we have?
5. Who receives the "unsure" emails?
6. Where does the experiment run?
7. When do we meet to look at results?

Also waiting on Reid: review "What a document record holds" (under Shared files) and its three questions.

To restart

Joe: rejoin the call in Chrome and run /meet. Today's page continues; nothing is lost.

The documents are there, and what's left to settle

Good news: the documents are there

I checked the files in all 48 deal folders, not just the answer keys. (I went by file names, so treat these counts as close, not exact.)

• Division orders: plenty (Reid was right). The answer keys don't point to them, but they already hold the right decimal interest for each lease. A division order's numbers can be checked against those, so no new answers are needed.
• Check stubs: 13 is enough for a first look. Check them against Reid's historical revenue data.
• Tax statements: only 3 deals. Joe, this is the one type to provide more of, or drop it from experiment 1.
• Reid's point: the take-one-out test works on any type (letters, title opinions, anything else), not just paperwork that arrives after closing. Agreed. It also covers the front-end work during valuation and title.

What's left to settle before the experiment can run

1. Who builds the single-document path, and by when. This is the gate; nothing runs until it exists.
2. Approve the document record draft (under Shared files) and answer its three questions.
3. The 25–30 documents. I can propose the exact list now from the folders above, spread across types and deals, for Reid to approve.
4. The scorecard: what counts as a pass for each measure, including the most important one, "wrong and didn't ask".
5. The unsure emails: who receives them, and from which account. Internal only.
6. Where it runs (Reid's machine or a server) and when we meet to look at results.

Shared: What a document record holds (draft for Reid)

What a document record holds (draft for Reid) shared by Claude. Discuss it on the Discussion page.

Decided, and a catch in the test plan

Decided

• 25–30 documents, across all 8 types.
• Build the proper single-document path first, then run the test.
• Unsure documents go by email to the person on point during the test. These are internal emails only; nothing goes to operators.
• Claude drafts what the new database table holds, for Reid to review. It's below, under Shared files.
• Two things being measured (Joe): how good each step is, and whether the whole thing runs end to end with very little supervision. For example, someone asks it something in Teams and it carries out the work.

Reid's test idea for flow 0, and one catch

The idea: our answer keys already say which document each fact came from. So take a document out (say a division order), give the raw document to the system, and see if it fills back in what's now missing. No new answer key needed.

The catch: I checked the answer keys for all 48 deals. Their sources are mostly allocation tables, conveyances and assignments, letters, and title opinions. Division orders, check stubs and tax statements barely appear, so this test can't score those yet.

• For check stubs, Reid's historical revenue data could serve as the answer.
• For division orders and tax statements, someone needs to write the answers for a handful of them.

Suggestion: run Reid's take-one-out test on the four types the keys already cover, and hand-check about 10 documents of the other types.

Feedback on your answers

Overall: solid answers. Pulling facts first, using our own database and a citation viewer for checks all fit what you decided yesterday. Four things are worth tightening before Reid runs anything.

1. Ten documents can't cover eight types

Eight document types across 10 documents is about one of each. One example per type can't tell you if a type works. Suggestion: either focus on the 3 or 4 most common types (say deeds, division orders, check stubs and leases), or raise the test to 25–30 documents.

2. "Certain" has to mean evidence, not a feeling

AI tools tend to say they're sure when they aren't. Since the worst mistake is wrong ownership or money, "certain" should mean it can point to proof: a tract, lease or owner name in the document that matches the deal. If it can't point to it, it asks. The scorecard should count separately the times it was wrong and didn't ask. That's the number that matters.

3. The right long-term choice adds build time

A proper way to send one document through is the right long-term choice, but it has to be built in the deal-data project before the test can start. Option: for experiment 1, treat each document as its own tiny deal, which works today, and build the proper way in parallel. The test then starts days sooner, and its results shape the real version.

4. Expect more "unsure" than you'd think

Today the flow sees a whole deal folder at once. A single document has much less around it to go on, so it will ask for help more often. That's fine and worth measuring. For the test, unsure documents can simply go on a list in the results. Email or Teams can wait.

Also needed

What the new database table holds: what the document is, where it came from, the facts with page and quote, the deal it matched and why, and its status. I can draft this for Reid.

Three quick calls are on the Discussion page (question 4 above, plus these two).

Confirmed: what flows 0 and 1 are, and what you've decided

Yes, Reid's description is right

• Flow 0 is taking documents in. Every document that arrives (scanner, mail, email) lands in one place and becomes a record. We note what it is and where it came from, and pull out the facts.
• Flow 1 is filling the inventory from a closed deal. A closed deal's documents become the official inventory records.

Experiment 1 tests both, plus matching each document to the right deal.

What you've decided so far

• One document at a time: add a proper way to send a single document through, not a workaround.
• Where records live: a new table in the database we already use.
• The 10 documents: Claude suggests a mix from deals we already have answers for, and Reid approves.
• Facts first: pull the facts out of every document before deciding which deal it belongs to.
• Document types: all eight from the list (deeds, division orders, check stubs, leases, Excel allocation tables, title opinions, operator letters, tax statements).
• What the AI may decide alone in the test: all four calls (what it is, what it connects to, whether it's right, where to look next). That's safe because nothing leaves the building during the test.
• How sure before matching on its own: only when certain.
• Worst realistic mistake: wrong ownership or money later on. So the checks have to be strict.
• What a person sees when confirming a match: the page image, the quoted text, and which deal and why. Reid: "that's literally a citation viewer." We already have one: the review pages in the deal-data project link every quote to its page in the original document.

Still open

• Where unsure documents go: email, Teams, or a list on this site.
• Anything else that must be true before Reid runs it.

Simple language from now on

Got it. From now on, everything on this site is in simple language: short sentences, everyday words, and what it means for you before how it works.

Reid's idea for the layout, noted for later

• Right side: Claude as if it's in the meeting with us, talking.
• Left side: the things we ask it for, like documents, input on something, or questions it needs us to answer.

We agreed this can be built after a meeting, or during another call, so it doesn't slow us down now.

Today: open items, one at a time

Phase 1: settled enough to move on

From yesterday's form: the inputs are right, but the volume is unknown and could be much higher, so the experiment measures it. The outputs are confirmed. Must never happen: a person approves every outside email, for now. Past mistakes: unknown.

Open items, in order, all on the Discussion page

1. Experiment 1 (5 questions): how the flow takes one document; where records live; who picks the 10 documents; facts before or after matching; anything else.
2. Phase 2 for flows 0 and 1 (6 questions): which document types first; which judgment calls the AI makes alone; where unsure documents go; how sure before matching; the worst realistic mistake; what a person sees when confirming.

Press "Send answers" after each set. Answers aren't saved until you do; that's how yesterday's answers were nearly lost. Phase 2 for the later flows (4, 3, 7, 8) comes after the experiment.

UI/UX proposal

The Meet Notes UI/UX proposal is under Shared files. In short: one team-wide list of decisions, open questions and to-dos, each with an owner and the meeting it came from. Claude's replies fold up underneath. Meetings get readable names and a recap pinned at the top (Joe's ask from the call). It also has a To-dos page by person and a Files page. Answers save on every tap.

It flags one real problem: the Claude panel's "Heard" lines show raw caption snippets on the public page. I'd switch those to my cleaned-up version of the request.

Shared: Meet Notes UI/UX proposal

Meet Notes UI/UX proposal shared by Claude (Meeting Notes Specialist). Discuss it on the Discussion page.

Listening

Claude is listening. Say "Hey Claude, ..." in the call and the reply appears here.