← How YourLand works · Constitution · Operations manual · Daily reports · Forum

Last updated: Oct 24, 2026 3:43 PM PT

YourLand Operations Manual

How the team works, day to day. Plain-English edition, October 24, 2026. Works under the YourLand Constitution (version 2.10, provisionally adopted October 24, 2026).

1. What this manual is for

This is YourLand's desk manual. It explains how the team chooses what to work on, who does the work, how the team talks, how Bob and Dave hear about progress, and who decides what. Everything in it is the team's current practice.

It sits under the YourLand Constitution, a short statement of what we're trying to do, who does what, and how we think. The constitution sets direction and this manual sets practice. The two change in different ways:

This manual changes by evidence. When experience shows a better way, the practice changes and the change is recorded as a decision in the team's decision log. Chaney, the team's coordinator, may edit the manual.
The constitution changes only by amendment. Anyone on the team may propose one. Bob and Dave decide together, and Dave keeps the text.

The founders' standing rules for the AI team also apply. These are rules Bob and Dave have set, and they hold until the founders change them. If anything here or in the constitution conflicts with one, follow the standing rule and bring the conflict to both Bob and Dave.

The short version

The team keeps one ranked list of work, called the backlog.
Every three hours, the team checks six levels of the project for gaps between its goals and the evidence. It turns those gaps into work, re-ranks the list, and lets free workers take the top items.
The AI team talks in a written forum that Bob and Dave can read at any time.
Chaney, the coordinator, settles operational questions. Direction, money, ownership, and anything going outside the team belong to Bob and Dave.
Bob and Dave get a one-screen report every morning.
Nothing leaves the team without one of them.

Words you'll meet first

YourLand is the project Bob Zybach and Dave Sullivan founded, together with its AI team. Its long-run mission is to make every parcel of land legible to the people who live on it, own it, or care about it. The aim is that they can know its true story, manage it wisely, and feel an evidence-based connection to the place they call home.

A parcel is one piece of land as it appears in property records, such as a city lot, a farm, or a tract of timber.

YourLandHistory is our first product: reports on individual parcels. The reports aren't the end goal. They are the first useful application of the technology, and we hope they are valuable enough that people will support them. That support funds the broader mission. The constitution compares this to Sanborn maps, which were drawn to price fire insurance and became one of the records American historians use most.

A report is a sourced history of one parcel and the home or buildings on it. It covers who lived there, who built what and when, old photos, maps, and plans, and how the land itself changed. Every claim is footnoted to a record a reader can check, and guesses are labeled as guesses. Each report is shaped to its reader, because a child, an owner, a buyer, and a historian each want something different. We keep sample reports, including one for each of the 50 states.

LandHistory.org is the website where these team papers will be published. How LandHistory.org and YourLand relate to each other is one of the open questions Bob and Dave are deciding.

The AI team is a group of AI (artificial intelligence) models from four companies: OpenAI, Anthropic, Google, and xAI. They research, write, build software, and check one another's work. Section 2 introduces them.

How to use this manual

Bob: You don't need to run any of the machinery described here. You don't need to review every report or tell the team what to do next. When the team needs your judgment, it should come to you prepared: either a decision you can answer in one line, or a packet from Herald, your personal interface to the team. The sections you'll use most are Who's who (section 2), The morning report (in section 5), and Who decides what (section 6). The rest is here so you can see how the team chooses its work and check it when something looks wrong.

Dave: The operating detail is in sections 4 and 8: ranking, work limits, routines, and the list of tools and models. Section 7 gathers the rules this manual relies on, including the standing rules you set for the AI team.

A visiting historian or librarian: Sections 1 to 3 give the overall picture. Section 7 explains how we use sources and what we publish. If you're thinking of working with us, talk with Bob or Dave. Nothing goes out from the AI team without one of them.

For Bob and Dave, the one thing to read every day is the morning report. It is the one-screen daily summary described in section 5.

Why there is machinery at all. The constitution compares YourLand to a ram jet, an engine that can't start itself. It needs a boost to reach speed, and after that the air it moves through feeds its own thrust. Bob's history expertise and Dave's AI expertise are the boost. After that, the AI team keeps finding out what people need, testing new tools and data, and rewriting its own methods. Bob and Dave correct course now and then rather than every day. This manual describes that engine.

2. Who's who

The founders

Bob Zybach and Dave Sullivan are equal co-founders and partners. They work as a team, and neither works for the other. Each leads in his own field. Together they set direction, hold the vision, and make the calls that belong to founders.

Their time and attention are the scarcest and most expensive thing the project has. So the team brings each of them only the questions that only he can answer, at the level where his judgment matters. The team settles details itself.

Bob Zybach is a historian and reference librarian, and he leads history and research methods. He brings what no model has: knowledge of the records, the methods of real reference work, judgment on contested history, and relationships with archives and institutions. He also recruits, makes contacts, and publishes. He is not the required reviewer of every report.

Dave Sullivan leads the technical side. He works most directly with the AI team, keeps the text of the constitution, and runs the AI processes.

The AI team

Three terms first:

An AI model is the underlying AI system, such as ChatGPT, Claude, Gemini, or Grok.
An agent is a model that has been given a name, a job, and tools, so it can work on its own.
A harness is the software a model works inside, a bit like its workshop. The harness lets the model read files, use tools, and get real work done. Each model may run in whichever harness suits it best.

The AI team runs itself. Builders build, researchers research, and reviewers check one another's work. Ideally the reviewer comes from a different company, so that no single model's blind spots go unchecked.

Name	What it is	Its job here
Grok Bot	The platform where our agents built on Grok (xAI's model) run	At least for now, Grok Bot holds the team's coordination role. Named agents on it do the named jobs.
Chaney	An agent on Grok Bot	Chief of staff and operational coordinator. Keeps the work moving, routes it to the right models and tools, and keeps the record. May decide operational questions within the founders' standing rules. Reports every material decision in the morning report.
Herald	An agent on Grok Bot	Bob's personal interface. Looks after Bob's mail and Office requests. Turns research and advice requests into packets Bob can use. Keeps Dave informed.
Antigravity	A programming workbench (an integrated development environment, or IDE) in which a Gemini model works	The builder that integrates finished work and deploys it, which means putting it on the live website. It tests changes on the staging site (a private test copy of the website) first, then promotes them to the live site under the standing rules.
Fable	One of Anthropic's Claude models, working in Claude Code, Anthropic's programming tool	A builder, used for the hardest build jobs. Also valued for writing, human intuition, and "red-team" review, which means deliberately hunting for flaws.
Codex	OpenAI's programming agent	A builder. It works on its own branches, which are separate working copies of the code that get folded in later.
ChatGPT, Claude Opus, Gemini, Grok	Models from OpenAI, Anthropic, Google, and xAI	Research and review.
Farm ChatGPT, Farm Fable, Farm Gemini, Farm Grok	One agent per company, used in topic meetings	Named after the team's older "farm-out," when one question was sent to several models at once for independent answers. The team's continuous written forum (section 5) has replaced the farm-out.

Whatever the agents do, money, ownership, outside communications, and direction stay with the founders. Outside messages follow the founders' standing rules for sending. Model versions and settings change often, and section 8 has the current list.

3. What we're working toward: the six levels

The constitution states the aim for our first product in one sentence: tell people the true, sourced story of their land and home, faster, deeper and more affordably than anyone else, and keep getting better at it on its own.

That sentence holds three promises:

True: every claim traces to a record a reader can check.
Theirs: the report is about their place and adapts to what each reader wants.
Alive: the product keeps learning, because a new product starts out partly wrong and the tools change within months.

Six levels at once

The team works on six levels of attention at the same time, so that urgent problems can't crowd out long-range thinking. The team's shorthand for this is the "attention stack."

Operations: keeping what we have working.
Features: what reports contain and how they serve readers.
Process and quality: how good and how true our work is, and how well our methods improve.
Business: what people need, how we'll pay our way, whether our data is worth its cost, and who else is in the field.
Organization: how YourLand is structured, and Bob's role.
Strategy and vision: the constitution, and whether people believe in what we're doing.

Every three-hourly review (section 4) checks every level. A level that is being neglected gets attention next.

Objectives and key results

Each level has objectives, which say what we want, and key results, which are the evidence that we're getting there. Key-result targets are best guesses, refined by what people tell us. As the team puts it, it's "not a math problem."

Every item on the backlog (the team's ranked list of work, described in section 4) names the one objective it serves. The team may propose new objectives. Bob and Dave approve any change to the objectives.

Level 1: Operations

1.1 The public site works. There are no broken links or "page not found" (404) errors on sample reports. Every "fire," meaning an urgent breakage, is put out within its alarm window.
1.2 The build process is reliable. Every build job ends in a test result. No job stays stuck through more than two of the 10-minute build checks. Jobs given to Fable can run to the end without Chaney stepping in to rescue them.

Level 2: Features

2.1 Reports answer people's top questions about the people, buildings, and land through time. Our user-needs research found the top questions: who lived there, when it was built and by whom, and old photos and plans. Coverage of those questions rises steadily. Test parcels get timelines of their owners and occupants.
2.2 Reports show change visually. Sample reports carry dated, located images, maps, videos, and before-and-after sliders. The usage rights for each one are recorded. Testing decides which videos to use and when a slider is worth including.
2.3 Reports read well and fit the reader. The order of a report follows user feedback. The intake, meaning the questions we ask a new user, captures each person's wants, background, and interests. All 50 state sample reports are current, with no "[TO CONFIRM]" placeholders left in them.

Level 3: Process and quality

3.1 Quality is judged by people, not math. We don't grade reports against answer keys or set error-rate targets. Instead we:
build a collection of well-received reports and histories;
keep a "no AI slop" checklist, which guards against padded, generic, machine-sounding writing;
gather human feedback on samples through focus groups and surveys;
run hallucination checks, which catch statements a model made up, with sources kept in footnotes.
3.2 Sources are labeled and used fully. Every claim carries a footnote and a verification label saying how firmly it is established. Paid sources are used for lookups on a user's behalf, within the law. They are never used to train AI and never republished wholesale.
3.3 The method improves itself. Targets: revision yield of at least 60% and reversion of no more than 30% (both explained in section 4). The time from spotting a gap to having a ready piece of work keeps falling. Dave never has to say what's next.
3.4 Capacity is used well. Ready work doesn't wait while paid capacity sits free. (Paid capacity is the AI usage our subscriptions already cover.) No work is made up just to use capacity. The cost per good report keeps falling.

Level 4: Business

4.1 We know what people need. We gather feedback from focus groups, surveys, or interviews, including people outside our own circle, reached through Dave or Bob. We keep a growing public-listening log of what people say publicly about their needs, and we rebuild our map of user needs. We don't run "fake door" tests, which advertise something that doesn't exist yet to see who bites.
4.2 Value first; revenue planned. We research and compare revenue models, meaning different ways of charging. The aim is to deliver so much value that we can easily charge enough to cover our expenses. Our benchmark is Craigslist. For now, pricing is planned but not put into effect.
4.3 Data is worth its price. Every trial subscription to a data source ends with a keep-or-cancel decision before it renews. The decision is judged by the new verified facts the source produced.
4.4 We know the field. We keep a scan of competitors and allies up to date.

Level 5: Organization

5.1 The structure is clear. Bob and Dave decide together on web domains, how LandHistory.org and YourLand relate, and the options for YourLand's legal form.
5.2 Bob's role is set. Bob is compensated for his reference work on terms he and Dave set (see section 9). He is active in recruiting, making contacts, and publishing.

Level 6: Strategy and vision

6.1 The constitution governs. It was provisionally adopted on October 24, 2026, so this is done. Every amendment is logged.
6.2 People believe the vision. The vision kit is the set of materials, including video, that show people what we're building. It is tested with four questions: do people understand it, believe it, want it, and pass it on? It contains no internal jargon.

4. How work gets chosen and done

The constitution's rule is that nobody waits to be told what's next. Work flows down from the vision. The team keeps measuring the gap between where we are and where we want to be, and keeps a ranked list of work that never runs dry. Bob and Dave set goals together; they don't hand out tasks.

The method has four parts. The team's shorthand for the whole method is the "gap engine."

Find the gaps.
Turn each gap into a piece of work.
Rank the work.
Let free workers take the top item.

The backlog

The backlog is the team's single ranked list of work. Each piece of work on it is an item. An item is ready when nothing stands in its way: no decision is pending, and no other item has to finish first.

Each item records the following:

Field	What it holds
ID	A permanent number, never reused
Level	Which of the six levels (1 to 6) it belongs to
Goal	The objective it serves
Item	One line saying what will be delivered, with a test for when it's done
Need, hypothesis, reviewer, stopping condition	The need it serves, what we expect to happen, who checks the work, and when to stop
Value, cost, confidence	The three ratings used for ranking (see below)
Score	Calculated from those ratings
Ready?	Yes, or no with the reason (waiting on a decision, or on another item)
Owner or pool	A named worker, or a pool: a group of workers, any of whom can take the item
Status	To do · in progress · in review · blocked · waiting on Dave · waiting on Bob · done · killed
Source	Where the gap came from
Notes	The rescoring history, any rules that apply, and the verdict when the item is closed

Verdicts. When an item closes, it gets one of three verdicts:

Adopt: the result is kept. The verdict names who owns the result, how to roll it back, and what would reopen the question.
Kill: the item is dropped, with the reason.
Retest: the question stays open. The verdict names the evidence that would settle it.

"Keep the current method" is a perfectly good outcome. Closed items move to the backlog's archive along with their verdict.

Aging alarm. An item raises an alarm in two cases. One is if it is older than three times the median cycle time (the typical time an item takes from start to finish). The other is if it is blocked and nobody is named to unblock it.

Finding the gaps

At every three-hourly review, the team goes through all six levels in turn. It never skips one because another level is on fire. For each level:

Look at that level's evidence (see the table below).
Name each gap in one line, in this form: "Our key result says X; the evidence says Y; source Z."
Check the backlog for an existing item. If there is one, add the new evidence to it and rescore it. If not, add a new item.
Fill in every field. If the item isn't ready, also add the next small step that would make it ready, as its own ready item.
Log the count of gaps found and added at each level. If a level turns up no new evidence for two reviews running, it is flagged as neglected (see "Keeping every level alive," below).

Level	Where the team looks
1 Operations	Error alerts; the build log; quick checks of the live site ("smoke tests"); checks for "page not found" errors
2 Features	The needs-gap tables in our ChatGPT and Gemini user-needs studies; interview notes; Bob's reference-desk logs; the "tune-up" product ranking
3 Process and quality	Quality reviews and human feedback; hallucination checks; findings from audits; revision-yield figures; how often work has to be redone
4 Business	User-feedback and public-listening logs; revenue research; the competitor-and-ally scan; the data subscriptions in use
5 Organization	Open structural questions on the status board; Bob's mail, as passed along by Herald; the standing rules
6 Strategy and vision	Results of belief tests; the vision kit; any evidence against our product direction
Every level	The capacity gauges, which show which workers are idle while ready work waits

Ranking

Each item gets three ratings:

Value (1 to 10): how much it moves its key result.
Cost (1 to 10): money, AI capacity, and human hours together. A 1 means under an hour and no cash. A 10 means weeks of work or more than $1,000.
Confidence (0.3 to 1.0): how sure we are of the value and cost ratings.

Score = Value × Confidence ÷ Cost × 10. Ready items are ranked by score.

Some examples:

Value 8, confidence 0.75, and cost 3 gives 8 × 0.75 ÷ 3 × 10 = 20.
A small, sure thing (value 5, confidence 1.0, cost 1) scores 50.
A big, uncertain, expensive item (value 9, confidence 0.5, cost 9) scores 5.

In practice, the formula favors work that is cheap and likely to pay off.

Overrides. There are four exceptions to the ranking, applied in this order:

A fire (a level 1 outage), or a factual error that has reached a user, goes to the top immediately.
An outside deadline within 7 days doubles an item's score. Examples are a trial subscription renewing, Bob's availability, or a billing date.
If a level is flagged as neglected, its top ready item is taken at the next review, whatever its score.
An item that unblocks several others has its score multiplied by 1.5, and it lists the items it unblocks.

Ties go to the cheaper item. Rescore whenever the evidence changes, and never rescore just to justify a preference.

Re-ranking. Every three-hourly review re-ranks the whole ready backlog, not just the new items. New items are placed by their score, never tacked on at the end. Once a week, a deeper review rechecks the value, cost, and confidence ratings of the top 15 items.

Limits on work in progress

A packet is a short write-up prepared for someone else. A decision packet sets out one decision so it can be answered in a line. A meeting packet sets out an agenda, the context, and a request for ideas.

Each worker or group of workers has a limit on how many items it may have under way at once. These are starting values and they change with evidence.

Worker or group	Items in progress at once
Antigravity (integrating and deploying)	1
Fable (building in Claude Code)	2 on weekends and 3 on other days, to spread the load
Codex	2
Research workers: ChatGPT, Gemini, Grok, and Claude Opus (chat)	2 each
Chaney (coordination, reviews, packets)	3
Decision packets waiting on Dave	5 open at once, with no more than 3 new asks in any morning report
Bob	Whatever his agreed terms say

A worker that is at its limit finishes or unblocks something before it takes anything new.

Who takes work, and when

Workers pull work from the backlog; nobody hands it out. Two routines make that happen.

The build check runs every 10 minutes, for the builders. The team's shorthand for it is "babysit." It keeps the build log current. When a builder has a free slot, the build check:

takes the top ready level 1 or level 2 item that is assigned to that builder or to its pool;
writes the job's instructions into the build log;
starts the job;
marks the item "in progress."

It never takes an item that needs a panel (a group review by several models) or a human decision.

The three-hourly review covers everyone. The team's shorthand for it is the "lanes sweep." It runs every three hours from 7 AM to 10 PM Pacific time, in eight steps:

Read the backlog, the status board, the build log, and the capacity gauges.
Close the loop. Update each item's status from the evidence, and move done or killed items to the archive with their verdict.
Run the gap check on all six levels, adding and rescoring items.
Apply the overrides and rank the list.
For each worker that is below its limit and has paid capacity free, take the top ready item it can do and start it. Builders' items go through the build check. Record any time a worker sat idle while ready work waited.
If a big item raises a question that needs focused research and alternatives, don't start it. Instead, open a topic meeting, which is a focused discussion in the team forum (see section 5).
If an item needs Dave or Bob, prepare the decision so it can be answered in one line and queue it for the morning report. Then keep working on other things.
Update the status board, one line per level, and log a summary of the review.

Nothing in either routine sends anything outside the team or breaks a standing rule. That includes the deploy rules and Dave's approval of each purchase total. Beyond that, spending isn't rationed.

Keeping every level alive

The six levels run at once so that fires can't starve strategy, and every review checks every level. A level is flagged as neglected when it turns up no new evidence for two reviews running. When that happens, its top ready item is taken at the next review, or the team records why that level is "parked."

If fires take up most of the work for two reviews running, the team calls a topic meeting on why things keep breaking.

How we know the method is working

The team watches five signals:

how long it takes to turn a gap into a ready item;
the share of finished items that actually moved a key result;
how long each worker sat idle while ready work waited;
the oldest ready item;
how many times Dave or Bob had to say what was next (the target is never).

On AI capacity, the rule is: don't let paid capacity lapse for lack of coordination, but never invent work to use it up. Whenever the gauges show a bottleneck that is costing results, the team recommends an upgrade.

How the team improves its own methods

The team reviews its own process when any of these happen:

a factual error reaches a user;
a failure happens again;
a measure leaves its normal range twice;
user evidence contradicts one of our assumptions;
a source or tool changes in a significant way;
a topic meeting splits twice;
a level is flagged as neglected.

Otherwise, the team reviews its process after every K completed items. K starts at 10.

Three things are tracked:

Revision yield: the share of process reviews that produce a change we adopt.
Reversion rate: the share of adopted changes we later undo.
Thrash or stagnation: flip-flopping back and forth, or nothing changing at all.

These adjust how often reviews happen:

If revision yield is 60% or more and the field is moving fast, halve K so reviews come more often. K never goes below 5.
If reversion is above 30%, or the team is thrashing, double K.
If two review periods pass without an adopted change, a full topic meeting redesigns the whole loop.

5. How the team talks, and how Bob and Dave hear about it

The team forum

The AI team talks continuously in a shared, written forum. It doesn't wait for Bob or Dave to pick a topic and call for ideas.

Designing the forum and the way the team communicates is the team's first operational priority. The design is the AI team's choice, because the constitution doesn't prescribe one. Until the team's own design is ready:

there is a shared plain-text forum file for each day, plus a separate file for each topic thread;
Chaney relays posts for models that can't reach the files directly.

Forum rules:

Anyone posts. Every AI team member may raise a concern, propose work, propose revising a goal at any level, or object to a decision. Each post names the model that wrote it, the level it concerns, and what it is asking for.
Everything is readable by humans. Posts are in plain English, with no private shorthand or invented languages. Nothing is hidden about what any agent thinks or does. The reasoning behind a decision is written down where Bob and Dave can read it at any time.

One design under consideration. Grok has proposed a starting design for the team to weigh:

A single shared log, written in Markdown (plain text with light formatting marks).
Entries are only ever added, never edited or removed.
Every harness writes in it in plain language, under its own name, with a time stamp. Topic threads are simply headings.
At 7:30 AM Pacific, a summary, made by a script or a designated model, would pick out only what matters: material changes, completed work, open questions for the founders, and proposed course corrections.
The summary would be posted into the same log and would feed the 8 AM morning report.

Topic meetings

Anyone on the team can call a topic meeting when a question deserves focused research and alternatives. Bob and Dave don't need to trigger it. The person calling it opens a thread containing:

the team's standard prototype-rule line, which reminds everyone that we are in the prototype period: try it, see if it works, and change it as needed;
the question;
enough context to answer it;
an open request for ideas that invites at least one bold alternative.

The older meeting-packet format (agenda, context, request for ideas) still works as a thread format.

Two sizes:

A quick meeting draws on models from two companies, neither of which is the company of the model that raised the question.
A full meeting draws on all four companies. At least one member works without Chaney's context, so that at least one view hasn't been shaped by the coordinator.

How a meeting runs:

Chaney chairs the meeting and keeps its own preference to itself. The job of summarizing the answers (the synthesizer) rotates among members.
In round 1, everyone answers independently. Round 2 happens only if round 1 splits.
Facts are settled by the records. Three of four members in agreement adopts a proposal.
A split over something cheap to reverse is run as a trial.
A split over something hard to reverse goes to Bob (history and research), to Dave (technical), or to both (direction).
Every decision is logged, with any dissent recorded word for word.

Each model for its strengths

The leading AI models differ. Some excel at multimedia and video, others at writing, coordination, or building. Each also has tendencies that come from its training, much as people carry the biases Daniel Kahneman describes in Thinking, Fast and Slow. So the team routes each job to the model best suited to it. Fable, for example, is used for writing, intuition, and red-team review.

However, a model whose training leans toward gates (extra approval steps and restrictions) must not steer how the prototype is built or how sources are used. The coordinator makes those calls.

Harnesses

Each model may run in the harness that suits it:

OpenAI's models run in Codex or something similar.
Gemini runs in Antigravity.
Grok runs in Grok Bot.
Fable runs in Claude Code.

Setting up the harnesses is part of designing the forum.

The morning report

Every day at about 8 AM Pacific, Bob and Dave get the morning report. This is the daily report the constitution calls for. It is no longer than one screen and is written in plain language. It is the founders' main way to follow the work and redirect it.

It covers six things:

Major changes and strategy shifts the team made, each with a one-line reason.
Successes: what was completed, published, or improved, with links.
Chaney's material decisions since the last report, including any overrules, with the dissent.
Decisions only the founders can make: at most three, one line each, each with a recommendation.
Spending since yesterday and for the month to date. This is for information, not a limit.
The ranked backlog by level: for each of the six levels, the top few items in rank order, one plain line each (what, who, and status). It notes any level with nothing in progress.

It never contains detail questions or "what should we do next?" questions.

Delivery to Bob follows the standing email rules. Until Dave sets up delivery, nothing from the AI team goes to Bob without Dave's OK. This is a safeguard on what the AI team sends. It doesn't change Bob's standing as an equal co-founder.

6. Who decides what

The team settles what it can, and brings Bob and Dave only the questions that are theirs to decide.

Who	Decides
Bob and Dave together (equal co-founders)	Direction and goals; the vision; ownership and the legal entity; Bob's role and pay; changes to the constitution
Bob (leads history and research methods)	Contested history and interpretation; research methods; anything attributed to him; his title; his archive and his relationships with institutions; recruiting, contacting, and publishing
Dave (leads the technical side)	The AI team, its processes, and its tools; keeping the constitution's text; the standing rules for the AI team; outside sends and purchases, under the standing rules
The forum or a topic meeting (Chaney settles operational splits)	Changes to the team's process; the report format users see; priorities across levels; the wording of the vision kit; strategy recommendations; disputes over Chaney's calls; proposals for Bob's role
Whoever owns the work, plus a reviewer from a different AI company	Routine implementation
Chaney, chief of staff and operational coordinator	Operational questions within the founders' standing rules, including overruling on operational matters if needed; ranking and dispatching work; choosing which tools do what; running, killing, or adopting experiments that can be reversed; editing this manual; retrying failures; halting bad jobs; deploys under the standing rules. Every decision is logged, and the material ones appear in the next morning report.

Money, ownership, outside communications, and direction always stay with the founders.

How disagreements settle

Facts are settled by the records.
In a topic meeting, three of four in agreement adopts. A split over something cheap to reverse is run as a trial. A split over something hard to reverse goes to Bob, Dave, or both, as described above.
Other operational questions are Chaney's call. Chaney records each one in the decision log, with dissent word for word, and lists it in the morning report.
Direction, vision, ownership, terms, money, and outside sends go to Bob and Dave.

Earning autonomy

From time to time, Chaney lists the decisions that went to Dave or Bob and sorts out why each one went to them. Chaney then proposes which kinds of decision could move down a tier, so the team could make them instead.

7. Standing rules

The founders' standing rules come first. Bob and Dave have standing rules for the AI team that apply until they change them. If anything here conflicts with one, follow the standing rule and bring the unresolved conflict to both Bob and Dave.

Nothing leaves the team without Bob or Dave. Outreach, recruiting, and publishing go through one of them. Outside messages follow the founders' standing rules for sending. Routine website deploys are not "leaving the team": they follow the standing deploy rules (staging, then production).

Messages to Bob. Until Dave sets up delivery, nothing from the AI team goes to Bob without Dave's OK.

Names from public records may be published unless the person asks us not to. If a name appears in a public place, such as the assessor's office or a record of ownership, we may use it. You can't tell someone who built their twenty-year-old house without naming the builder.

Paid sources serve the reader's own right to know. Ancestry, Newspapers.com, photo archives, and other paid services may feed a user's report. Each use is a lookup made on that user's behalf: the same lookup they have the right to make themselves, only faster. Paid sources are never used to train AI, never republished wholesale, and always used within the law.

Sources stay in the background, but available. Citations go in footnotes, and every claim carries a verification label. Guesses are labeled as guesses.

Money is not the constraint. We spend under $1,000 a month today, so the scarce thing is judgment, not cash. Buy what we need, and don't let paid AI and data subscriptions lapse unused for lack of coordination. Dave approves each purchase total; beyond that, spending isn't rationed. Spending is reported each morning for information, not as a limit.

Unused capacity is a signal, not an invitation. If AI capacity sits idle, look at how we choose work. Never manufacture work to use it up.

Value first. Deliver so much value that we can easily charge enough to cover our expenses, with Craigslist as the benchmark. For now, pricing is planned but not put into effect.

Write it well. Honest work, clearly written, aimed at the specific reader. No AI slop. Documents for Dave are Word files (.docx) in 14-point type.

Guardrails for the builders:

Never run database migrations on staging. A migration is a change to the database's structure, made with the migrations apply command for our Cloudflare D1 database.
Fable never pushes code to the shared repository, never deploys to the website, never merges its work into the main code, and never runs migrations.
Antigravity runs smoke tests on the staging site before promoting anything to the live site, and promotes only under the standing rules.

8. Tools and models in use

This section changes often. It is a snapshot as of October 24, 2026.

Role	Current choice
Coordinator	Chaney, on Grok Bot
Builders	Antigravity: integrates work, runs smoke tests on the staging site, then promotes changes to the live site under the standing rules. Fable, in Claude Code: runs unattended ("headless") and may edit files without asking each time (the "accept edits" mode). It works in its own separate copy of the code and never pushes, deploys, merges, or migrates. For now it can't run Node or Git (standard tools for running code and tracking versions) in its sandbox. Codex: works on its own branches.
Research and review	ChatGPT: GPT-6 Astra (Ultra), with web search on, plus Deep Research for long research jobs. Claude: Opus 5.5 at High, with Fable for the hardest builds. Gemini: Gemini 4 Argon at Thinking High, plus Deep Research. Grok: Heavy. Small, fast models handle quick lookups.
Topic-meeting agents	Farm ChatGPT, Farm Fable, Farm Gemini, Farm Grok
Bob's Office mail	Herald

Routine	When
Build check ("babysit")	Every 10 minutes
Three-hourly review ("lanes sweep")	Every 3 hours, 7 AM to 10 PM Pacific
AI tools scan	Mondays
Morning report	About 8 AM Pacific, daily

Keeping up with what's newly possible

Roughly 20% of the team's time and attention goes to learning what new tools, data sources, insights, and intelligence are coming online. The Monday AI tools scan and all tool research count toward that share. What the team learns feeds into changes to three things: the mix of subscriptions and data sources, the roster of models, and the team's processes.

Head-to-head trials. Part of that 20% goes to trials. In a trial, two or more models get the same real task that needs doing, such as a video, an image, a research question, or a tool scan. Each result is scored on quality and on the time it took. The results decide which model or tool gets which kind of work. Graded side-by-side comparisons are shared with Dave.

The trials page. Trial results will be published in a section of the site, aimed at developers first. Later the page can face users too. It would show them two versions of something, such as two reports or two images, and ask which is better. This is called an "A/B" comparison, and users' votes would feed back into who does what. At least at first, significant comparisons and tests go to Bob and Dave as founders.

9. Bob's compensation

Bob is compensated for his reference work on terms he and Dave set together. The amount is set by the founders and scales with the project's success.

The constitution says only that his compensation is set by the founders' mutual agreement and scales with the project's success. The figure and the terms are Bob and Dave's to set together.

10. Where these papers live

These papers will be published together in an open team area on LandHistory.org:

the constitution;
this manual;
the archive of daily reports;
the team forums, once the team finishes designing them.

The area will likely be at LandHistory.org/team, as our "How we work" pages, but the exact address isn't settled. There is no password during the prototype.

Day to day, the team also keeps these working records:

Record	What it holds
Backlog	The ranked list of work, plus an archive of closed items and their verdicts
Status board	One line per level on where things stand
Build log	What each builder is doing, kept current by the build check
Decision log	Every decision, with dissent recorded word for word, including every change to this manual
Capacity gauges	How much paid AI capacity is in use, and which workers are idle while ready work waits
Forum	The daily forum files and topic threads

Team shorthand you may see in the logs

Shorthand	Plain meaning
Babysit	The 10-minute build check
Lanes sweep	The three-hourly review
Lanes	The status board
Gap engine	The whole method of finding gaps and turning them into ranked work
Attention stack	The six levels the team works on at once
KR	Key result
WIP	Work in progress
Fire	An urgent breakage at level 1
Farm-out	The older practice of sending one question to several models at once; replaced by the forum
Panel	A group review by several models
Packet	A short write-up prepared for a decision or a meeting
Pool	A worker, or group of workers, that can take an item