# Protocol v1.0.0: Ranch.Bot record-keeping observation on approximately 200 ewes as of 2026-08-23

- Protocol finalization date: 2026-08-25
- Observation window: 2026-10-01T00:00:00-06:00 through 2026-11-30T23:59:59-07:00
- Planned report publication: 2026-12-15 through 2026-12-31
- Operator and protocol owner: Jerremy Lewis
- Setting: a working Alberta sheep operation with approximately 200 ewes as of 2026-08-23
- Product: Ranch.Bot Livestock Records
- Protocol status: pre-registered before observation

## Purpose and limits

This is a prospective observational field report of record capture on the founder-builder's own sheep operation. It is not a customer case study, testimonial, controlled trial, or comparison with another record system. It will describe what happened when eligible events were entered through Ranch.Bot's SMS capture and web review workflow.

The report cannot establish that Ranch.Bot improves lamb survival, conception, health, profitability, productivity, safety, or veterinary outcomes. It cannot establish universal time savings. The founder-builder is also the operator, product owner, and protocol owner. That conflict will be repeated in the report.

## Operator and consent

The named founder-operator is the only enrolled operator. Protocol approval and publication record the operator's consent to collect workflow measurements and publish aggregate results and redacted traces under this protocol. Events observed or entered only by family members, workers, veterinarians, or other third parties are excluded. No third-party name, message, image, voice, or private property is part of the public dataset without separate written permission.

## Pre-publication review

- Product reviewer: Jerremy Lewis, founder-builder, 2026-08-25. He checked the product claim slice against the current implementation. This is not independent review.
- Editorial reviewer: Jerremy Lewis, founder-publisher, 2026-08-25. He checked the protocol against the publication gate, identity boundary, and no-results-before-close rule. This is not independent review.
- Specialist determination: no specialist reviewer is required for this protocol-only release because it makes no treatment, genetics, regulatory, or husbandry recommendation.

The founder-builder is the operator, protocol owner, product reviewer, and editorial reviewer. Final disagreement adjudication still requires a reviewer who did not perform the input attempt. The report will name that reviewer and any specialist required by the events safe to show.

## Eligible flock and events

The eligible flock is the operation's sheep inventory during the observation window, described publicly only as approximately 200 ewes as of 2026-08-23 plus related sheep groups. An `eligible_real_world_event` is a real sheep event that the enrolled operator personally observes or performs during ordinary work, would normally preserve as a livestock record, and can describe with an event date and an animal or group when one is known.

Eligible event types are those supported by the deployed product during the window, including birth, breeding, health observation, treatment, movement, weight, identifier, and other dated management records. All eligible events are sampled consecutively.

Excluded before analysis:

1. events outside the fixed observation window;
2. synthetic tests, demonstrations, training entries, and software-quality checks;
3. retrospective data cleanup, concierge imports, and bulk backfills;
4. non-sheep events;
5. events only another person observed or entered;
6. events for which the independent source note was not started before the first Ranch.Bot input;
7. events whose inclusion would disclose a third party or sensitive location and cannot be safely redacted.

Every exclusion receives a reason code. An eligible event remains in the denominator after an input failure, abandonment, or missing product artifact. Missing outcomes are reported as missing, not removed.

## Linked units

Each unit receives a study ID that contains no animal tag, phone number, or farm identifier.

- `eligible_real_world_event`: one real occurrence or one deliberately batched same-type group occurrence recorded in the independent source log.
- `input_attempt`: one SMS sent with the intent to capture one linked eligible event. A retry or rewritten note is another attempt.
- `proposal`: one structured write proposal returned by Ranch.Bot. Clarifying questions and error replies are not proposals.
- `review`: one inspection of a proposal that ends in confirm, cancel, or cancel followed by a corrected input. Opening the same unchanged proposal twice is one review.
- `saved_record`: one persisted Ranch.Bot record produced after confirmation. An unintended second record for the same intended event is linked and counted as a duplicate.
- `exported_record`: the corresponding record object in the end-of-window structured JSON export.
- `exported_row`: the corresponding line in the end-of-window simplified CSV export.

The study linkage table records `event_id`, attempt sequence, proposal sequence, review sequence, saved record ID, exported record ID, and exported row number. Public files will not include internal IDs or the linkage table.

## Independent source log and adjudication

The Ranch.Bot database is not the gold standard. Before the first Ranch.Bot input for an event, the operator starts a consecutively numbered paper source note with the event time, event type, animal or group as known, and the facts expected in the saved record. The operator signs any later addition and does not erase the original text. The source pages are photographed at the end of each observation day, stored privately, and hashed with SHA-256. The daily hash ledger is append-only during the window.

After the window, the source note is compared with input messages, proposals, review decisions, saved records, retrieval results, and exports. A reviewer who did not perform the input attempt checks every disagreement against the contemporaneous paper note and product artifacts. The report names the reviewer and states any relationship to Ranch.Bot. If the evidence does not resolve a disagreement, the value is `unresolved` and remains in the relevant denominator.

## Product version, device, and connection

The starting product version is the production git commit deployed at 2026-10-01T00:00:00-06:00. Its commit SHA, browser version, phone operating-system version, and device model will be reported. Each attempt records the deployed commit SHA, entry channel, connection condition, and whether the operator was indoors, in a vehicle, or outdoors. Signal strength is reported only as the device's displayed category: none, weak, moderate, or strong.

Every production deployment during the window is logged. Metrics split into before-and-after strata when a release changes SMS receipt, record interpretation, clarification, proposal fields, review controls, save behavior, lookup, or export. Cosmetic and copy-only changes are logged but do not create a version stratum. An emergency fix follows the same rule. Results are never pooled across materially different versions without also showing each stratum.

## Timing method

The operator uses a separate stopwatch and records whole seconds on the paper source note.

- capture time starts when composing the first SMS begins and stops when it is sent;
- proposal latency starts at the SMS sent timestamp and stops when the proposal reply reaches the phone;
- review time starts when the operator opens the proposal for a decision and stops at confirm, cancel, or sending the first corrected input;
- retrieval time starts when the operator begins the scheduled lookup and stops when the intended record is found or the attempt is abandoned after five minutes;
- export time starts when export is requested and stops when the file download completes or fails after five minutes.

Interruptions unrelated to record keeping are marked and excluded only from timing summaries, not from success or failure denominators. The report gives the interruption count and affected unit count. No timing value is replaced or estimated.

## Pre-specified metrics

All metrics report numerator, denominator, count missing, and percentage when a percentage is useful. Event, attempt, proposal, review, saved-record, retrieval, and export units are not blended.

1. Event capture: eligible events with at least one input attempt divided by all eligible real-world events.
2. First-attempt success: eligible events that produce a source-consistent proposal from the first input, require no clarification or correction, and complete save, divided by eligible events with a first input attempt.
3. Retry rate: eligible events with two or more input attempts divided by eligible events with any input attempt. Attempt counts are also reported.
4. Clarification rate: input attempts followed by a product clarification before any proposal divided by all input attempts.
5. Proposal yield: proposals divided by input attempts, with zero, one, and multiple proposals per attempt shown separately.
6. Review correction rate: reviews ending in cancel followed by a corrected input divided by all completed reviews.
7. Save completion: confirmed proposals that produce the intended saved record divided by confirmed proposals.
8. Unintended duplicate rate: saved records adjudicated as unintended duplicates divided by all saved records linked to the observation.
9. Identifier match accuracy: proposals with a source-consistent animal or group match divided by proposals for which the source note specifies an animal or group.
10. Required-field completeness: source-required fields present and source-consistent in the proposal, then in the saved record, divided by source-required fields for each unit. Proposal and saved-record values are separate.
11. Retrieval success: scheduled retrieval attempts that find the intended record within five minutes divided by all scheduled retrieval attempts.
12. Export reconciliation: in-scope saved records represented once in structured JSON and once in simplified CSV, divided by all in-scope saved records. Field reconciliation covers only fields each current export format claims to contain. Known export omissions are not counted as errors.
13. Time: capture, proposal latency, review, retrieval, and export times are reported separately as count, median, minimum, maximum, and interquartile range. Interrupted timings are listed separately.

## Retrieval and export checks

At the end of each observation week, every saved record is eligible for retrieval. If the week has 10 or fewer records, all are tested. If it has more than 10, the 10 records with the smallest SHA-256 value of `protocol_version + week_end_date + saved_record_id` are tested. The method is deterministic and selected without looking at success.

After the observation window, one structured JSON export and one simplified CSV export are retained privately and hashed. Every in-scope saved record is reconciled by record ID where the format includes it, then by the format's documented fields. Animal and group associations omitted by the current general export are reported as product limits, not reconciliation failures.

## Missing data, abandonment, and failure taxonomy

A missing paper source note makes the event ineligible under the pre-specified rule and is reported as an exclusion. Missing product output after an eligible input remains a failure or missing outcome in its linked denominator. An event is abandoned when the operator stops trying before a saved record exists; the last observed stage and reason are retained.

Failures use these pre-specified classes:

- capture or carrier failure;
- delayed or missing reply;
- clarification did not resolve;
- wrong event type;
- wrong animal or group match;
- missing, added, or changed field;
- proposal could not be reviewed;
- confirm did not save;
- unintended duplicate;
- retrieval failure;
- export missing, duplicate, or changed value;
- operator error;
- unresolved.

A failure may receive more than one class. Counts by class and by linked unit are reported. Successful, corrected, abandoned, and failed examples remain in the private study archive.

## Privacy, release level, and public traces

Raw paper notes, messages, internal IDs, animal identifiers, phone numbers, timestamps precise enough to expose routines, and row-level exports remain private. Public results use aggregate counts and a data dictionary. Small cells that could expose a person, sensitive event, or location are combined or withheld with a reason.

The report will include three permissioned, redacted traces selected before outcome scoring from three event-type strata with enough eligible events. Each trace shows raw note, proposal, correction or approval, saved record, and retrieval or export result. If fewer than three safe traces exist, the report publishes fewer and says why. Selection cannot exclude a trace because it failed.

The versioned aggregate release contains no row-level farm data. It includes metric name, unit, product-version stratum, numerator, denominator, missing count, value, exclusion count, and notes. The data dictionary defines every column and withheld value.

## Protocol version, hash, corrections, and report

This file is protocol version 1.0.0. Its SHA-256 digest is published beside it and on the canonical field-report page. The versioned URL and bytes are not overwritten after publication.

A material protocol change creates a new versioned file with its own timestamp and hash. It does not replace this version. Changes made before the observation starts are listed in a version table. Changes after the start are deviations, dated and explained in the report. Typographical corrections use a dated erratum that preserves the original file and states whether interpretation changes.

The report is planned for 2026-12-15 through 2026-12-31. It will publish the observation counts, denominators, exclusions, missing data, version strata, failure taxonomy, product changes, three safe traces when available, aggregate file, data dictionary, conflict disclosure, and limits. If reconciliation or privacy review is not complete, publication is delayed and the page states the reason. No result is drafted before the observation closes.