# Worked research dossier: search for a small documentation site

**Public copy prepared 2026-10-22.** Pins re-checked: none apply; every source card below is fictional. The companion article's one external source (Anthropic's multi-agent research report) was re-read 2026-10-22 and is recorded in the series source record; not re-checked: nothing.

**Supports:** [Build a research assistant whose work you can use](/blog/a-research-assistant-whose-work-you-can-use). Hub: [Delegation review kit](/resources/delegation-review-kit).

**Entirely fictional teaching case, authored 2026-09-15.** Every organization, source card, capability, cost and requirement below is invented. These are explicit scenario inputs, not externally observed product facts, quotations, interviews or test results. No system was built. Real methodological sources are separate in [the series source record](/research/delegation-series-sources.md).

## 1. Owner's decision and constraints — F01

Choose which search design deserves a prototype for an internal documentation site. This is a prototype-selection decision, not permission to deploy.

- 800 text documents; 120 staff users; all authorized users have identical document access today.
- No public access to content, titles, snippets or indexes. The search experience must use the site's authenticated boundary.
- Documents should become searchable within 24 hours of a change.
- Each result must point to its source document. Generated answers are optional, not required.
- Recurring cash spend should be at most $60/month at the assumed volume.
- At most two engineer-days for initial prototype work; assume eight hours/day for arithmetic.
- Owner prefers low recurring maintenance and accepts lexical search if representative questions can be answered through it.
- Per-team permissions may be requested later; no timeline or design is established.

**Scenario date:** 2026-09-15. Owner constraints outrank candidate proposals. A vendor's description cannot relax them.

## 2. Bounded source cards

These cards are short enough to inspect completely. IDs link recommendation claims back to the exact assumption supporting them. Dates belong to the invented scenario.

### F02 — Design A: index within the current site

Fictional engineering proposal, 2026-09-14, revision 2. Build a lexical index and serve it through the same authenticated boundary as the documents. No generated answers. Results include document links. Schedule indexing every six hours; estimated build duration up to two hours under expected load. The paper timing bound is eight hours after a change; no measured run validates it. Incremental hosting is estimated at $10/month, prototype effort at one day, maintenance at one hour/month. Access-boundary behavior and search usefulness are untested.

### F03 — Design B: hosted search, older overview

Fictional supplier overview, 2026-06-01. Describes per-team access filtering, a $40/month plan and indexing within 15 minutes. Does not specify which plan includes access filtering or the query volume allowance.

### F04 — Design B: hosted search, current plan specification

Fictional supplier specification, 2026-09-10. $40/month at the scenario volume. Basic plan supports one shared collection with authentication enforced by the consuming application. Per-team filtering is available only on a $90/month plan. Describes 15-minute indexing as a service target, not a guarantee. Results link to source documents. Estimated application integration effort and support time are not supplied.

### F05 — Design C: custom semantic retrieval

Fictional engineering proposal, 2026-09-14. Retrieval plus optional generated answers. Document links are part of the planned response. Estimated inference/storage cash cost of $35/month under a stated low-volume assumption; not a price quote. Prototype estimate: three days; maintenance: three hours/month. Authentication, source attribution and update timing remain implementation work. No quality evaluation exists.

### F06 — Example tasks from the owner

Fictional task list, 2026-09-15. Staff need to locate procedures with known names, find documents when they remember a synonym, and identify the current policy when obsolete versions remain. The list expresses requirements; nobody was interviewed. The owner proposes a future set of 20 representative questions, including exact-title, paraphrase and version-conflict questions. No search result or measured success rate exists yet.

## 3. Claim register

| Claim | Source | Status and confidence within the scenario | What would settle the uncertainty? |
|---|---|---|---|
| A fits the prototype effort limit | F01/F02 | Estimate fits: one day versus two permitted; medium | Time the prototype work |
| A can meet freshness requirement on paper | F01/F02 | 6h interval + 2h estimated build = 8h, below 24h; medium | Measure delayed/failed rebuild behavior; define alert/recovery |
| A preserves private access | F02 | Proposed design only; low until checked | Test signed-out access and all index/snippet paths |
| B's $40 plan includes per-team filtering | F03 versus F04 | Rejected for current plan: newer specific document limits that feature to $90 | Recheck if actual requirement becomes per-team access |
| B may fit today's shared-access requirement | F01/F04 | Plausible; application must enforce access; medium-low | Validate integration design and effort |
| C improves useful search quality | F05 | Unknown; no comparative evidence | Run representative questions against A and C |
| C fits the initial effort limit | F01/F05 | No on current estimate: three days versus two | Reduce scope or explicitly revise owner constraint |

Confidence here describes how well the fictional evidence supports the fictional claim. It does not establish confidence in any real product.

## 4. Completed decision brief

**Recommendation:** prototype A first. Its proposed design reuses the existing site boundary, fits the stated effort estimate and supports source-linked results. Its freshness arithmetic is compatible with the owner's limit. The estimates justify choosing A for prototype work. Deployment remains conditional on checking the access boundary and representative search tasks; those checks are outputs of the prototype, not prerequisites for starting it.

| Requirement | A: existing-site index | B: hosted search | C: semantic retrieval |
|---|---|---|---|
| Private shared staff access | Proposed; must test all serving paths | Application responsibility; integration unresolved | Proposed; implementation unresolved |
| Source document links | Included in design | Described in current specification | Included in design |
| ≤24h freshness | 8h paper bound; failure recovery unknown | 15min target, no guarantee established | Not specified |
| ≤$60 monthly cash | $10 estimate | $40 at scenario volume | $35 estimate |
| ≤2-day prototype | 1-day estimate | Unknown | 3-day estimate: exceeds limit |
| Task usefulness | Untested | Untested | Untested |

**Why not B first?** Its recurring cash cost fits and it may reduce maintenance, but integration effort is unresolved and there is no demonstrated quality advantage. The older overview was ambiguous about which features the $40 plan includes; the current specification clarifies the limitation. That does not automatically rule B out: today's requirement is shared access, not per-team filtering.

**Why not C first?** The current estimate exceeds the effort constraint, and the need for semantic retrieval or generated answers has not been established. It remains an alternative if simpler search fails meaningful tasks.

**Strongest objection to A:** lexical retrieval may perform poorly on paraphrases. If users cannot find the needed documents, lower cash cost does not compensate.

**Important future risk:** per-team permissions would change the decision. It requires a fresh design review for A and C and crosses B's current cash cap if its $90 plan is needed. Do not buy flexibility for an unspecified future requirement without considering its cost.

**Next validation:** assemble the proposed 20-question task set before comparing outputs. Define useful retrieval as the current authoritative document appearing within the first five results; score exact-title, paraphrase and stale-version cases separately. As an initial owner policy, require at least 18/20 overall and no obsolete document ranked above the current authoritative document in the designated conflict cases, with obsolete results visibly labelled as such. These thresholds are proposed judgements, not research-backed universal standards. Validate signed-out denial for documents, index files, titles and snippets before any real deployment. Record inability to assess an item as unknown, not pass.

**Reversal condition:** choose B for the next comparison if A misses useful questions and B's integration fits the effort limit; consider C if a demonstrated semantic requirement justifies revisiting the scope. Reassess all options if access requirements change.

**Stop research now:** extra feature comparisons cannot establish actual search quality or integration effort. The decisive unknowns require a small implementation/design check, not more source collection. That work remains unexecuted.

## 5. Optional economics view

At an invented $90/hour time valuation and F02/F05 maintenance estimates, A is $100/month including maintenance time ($10 + $90); C is $305/month ($35 + 3 × $90). B is $40 plus unknown support/integration maintenance. It would cost less than A on this narrow recurring comparison if maintenance took less than 40 minutes/month. That is a break-even condition, not a forecast. Initial effort and outcome quality are separate.

Do not mark missing maintenance as zero or rank options solely by cash. This is the bridge to [the third article](/blog/the-cheapest-agent-can-be-the-most-expensive-workflow).