What Comes After Hotel Source Acquisition: The Next Kanban Cards

Hotel source acquisition now has a production boundary. A controller can start with a stable property identity, ask a local model for bounded searches and source selections, retrieve and validate the pages deterministically, and finish with an immutable package of local text. The next question is operational rather than conceptual: what should appear on the Kanban board after that package is ready?

The answer is not another broad card that says “research the hotel.” Step 2 should begin with small extraction packets, followed by deterministic validation and a coverage decision. The Omni Mount Washington Resort & Spa production smoke test gives us a concrete example.

The Step 1 handoff

The successful run retained four source texts:

• one verified official property source;
• three distinct independent or guest-source corpora;
• matching SHA-256 hashes for every local text;
• a package status of ready_for_extraction;
• an explicit web_access_allowed: false instruction for downstream work.

The package itself is authoritative. Kanban is a human-visible dispatch and status projection. If the board is damaged or rebuilt, the package, receipts, hashes, and workflow state remain the source of truth.

The actual Step 2 input

The first version of this post described the cards but did not include their concrete input. That was an omission. The following is the actual frozen input from the successful Omni production smoke test, with machine-specific absolute path prefixes shortened to paths relative to the run workspace.

{
  "schema_version": 1,
  "subject": {
    "subject_id": "omni-mount-washington-resort-production-smoke",
    "canonical_name": "Omni Mount Washington Resort & Spa",
    "full_address": "310 Mount Washington Hotel Road, Bretton Woods, NH 03575, United States"
  },
  "status": "ready_for_extraction",
  "web_access_allowed": false,
  "package_file_sha256": "e87cf26631c8ef40bdb56003d6d393ef868c2625065f885af2969f6779ab6403",
  "package_content_sha256": "1a73e06b6051e2ce2fce8ed93ffc626114ab9961b852bfc7d7391951697b87a0",
  "allowed_source_ids": [
    "OFFICIAL-1",
    "GUEST-1",
    "GUEST-2",
    "GUEST-3"
  ],
  "usable_guest_count": 3
}

Frozen source manifest supplied to extraction

Source ID	Class / family	Local text artifact	Text SHA-256
OFFICIAL-1	official property	sources/R001-local/r001.txt	ff47a68869e85fd7f22f0f80f581f11dea65d9fd9b417682c55a22a83458b69c
GUEST-1	independent/guest — Tripadvisor	sources/R010-local/r010.txt	430c35dfc78991e8ee2b9722fae70926704d216f86536d8c1b473b26ec16e476
GUEST-2	independent/guest — U.S. News	sources/R015-local/r015.txt	fbf166d02478dd20c739d10b813cbddbfcd7c7eba4a208567adc8d6df04702d7
GUEST-3	independent/guest — Expedia Group	sources/R016-local/r016.txt	6f1c757f8fc7efe61be5262b22c05a010f9d51ba85a21fcb61a6abc255ff5039

Canonical source URLs represented by those files

• OFFICIAL-1: Omni Hotels’ property page
• GUEST-1: Tripadvisor’s property review corpus
• GUEST-2: U.S. News Travel’s property review
• GUEST-3: Hotels.com’s property corpus

Exact packet assignments

{
  "packet_id": "001",
  "subject_id": "omni-mount-washington-resort-production-smoke",
  "source_ids": ["OFFICIAL-1", "GUEST-1", "GUEST-2"],
  "web_access_allowed": false,
  "output": "extraction/packet-001/claim-ledger.json",
  "receipt": "extraction/packet-001/extraction-receipt.json"
}

{
  "packet_id": "002",
  "subject_id": "omni-mount-washington-resort-production-smoke",
  "source_ids": ["GUEST-3"],
  "web_access_allowed": false,
  "output": "extraction/packet-002/claim-ledger.json",
  "receipt": "extraction/packet-002/extraction-receipt.json"
}

Before a local extractor reads any text, the controller must verify the package-file hash and each listed source-text hash. The model receives the literal contents of only the files assigned to its packet, plus the subject identity and extraction schema. Search results, failed pages, unrelated local files, and live web tools are not part of the input.

The board hierarchy

Research project: general-hotel-reviews
└── Source acquisition for Omni Mount Washington Resort & Spa [complete]
    ├── Extract evidence packet 001 [local-extractor]
    └── Extract evidence packet 002 [local-extractor]

The project card is an unassigned container. The property card records the terminal Step 1 result. Only the two bounded extraction leaves are executable local-model tasks. This hierarchy becomes important when several hotels, restaurants, and attractions are moving through the system at once: every artifact and card remains attached to one project, one entity type, and one stable subject ID.

Card 1: extract evidence packet 001

Title: Extract Omni Mount Washington Resort & Spa evidence packet 001

Operation class: quotation_extraction
Assignee: local-extractor
Execution mode: local agent
Skill: local-evidence-extraction

Inputs:

• OFFICIAL-1 — the verified official property source;
• GUEST-1 — the first independent or guest corpus;
• GUEST-2 — the second independent or guest corpus;
• the frozen package path and package-file hash;
• the exact local path and SHA-256 hash for each source text.

Objective: Extract literal quotation-backed facts about exactly this hotel. Every proposed fact must carry the subject ID, source ID, and a quotation that appears literally in the supplied local text.

Restrictions:

• do not browse or search;
• do not replace a source;
• do not infer absence from a missing mention;
• do not write review prose;
• do not transfer brand-wide or nearby-property facts to this subject;
• stop on a missing file, hash mismatch, malformed response, or unsupported claim.

Outputs: one packet-level claim ledger and one extraction receipt containing model, route, machine, token counts, elapsed time, failures, and retries.

Card 2: extract evidence packet 002

Title: Extract Omni Mount Washington Resort & Spa evidence packet 002

Operation class: quotation_extraction
Assignee: local-extractor
Execution mode: local agent
Skill: local-evidence-extraction

Input: GUEST-3, the third independent or guest corpus, plus the same frozen package identity and hash boundary.

This is intentionally a separate card even though it contains only one source. The extraction packet limit is three texts, not a target that every packet must reach. Keeping the fourth source separate avoids creating one oversized model context and gives deterministic validation a clean packet boundary.

The objective, restrictions, telemetry, and output contract are identical to packet 001. The model cannot browse, improvise another source, or silently convert a thin source into confident claims.

Cards that follow extraction

The two model cards should not certify their own evidence. Their immediate descendants should be deterministic.

Card 3: validate packet 001

• verify the package and source hashes;
• verify that every source ID belongs to the allowlist;
• find every quotation literally in the referenced local file;
• reject cross-subject, malformed, unsupported, or duplicate rows;
• write a packet audit and validation receipt.

Card 4: validate packet 002

Apply the same deterministic checks to the second packet. A fluent model response is not accepted evidence until this card passes.

Card 5: merge accepted claim ledgers

Merge only accepted rows from both packet audits. Preserve quotations and source references exactly. Conflicting sources remain visible; the merge step does not rewrite disagreements into false consensus.

Card 6: classify coverage

Map the validated claim ledger into explicit coverage states for identity, rooms, amenities, pool, on-site restaurants, operations and policies, and destination access. The allowed states include present, missing, unknown, and not_applicable_with_explicit_evidence. A missing mention remains unknown, not proof that a feature is absent.

Card 7: named gap-fill, only if required

If coverage exposes one precise deficiency, the controller may create one narrowly scoped repair card—for example, “find a usable official parking-policy page” or “find one additional independent property-level corpus.” The repair gets a small query and retrieval budget and cannot restart the entire research run. Yelp remains forbidden, previously failed source families are not blindly repeated, and failure after the bounded repair leaves the subject blocked with an honest receipt.

Card 8: seal the extraction handoff

When validation and coverage pass, seal the combined ledger, packet audits, source package, telemetry, and coverage manifest. That sealed artifact—not the visual card state—becomes the input to later hotel-specific evidence modules and, eventually, local drafting.

Why this structure scales

Every executable card has one operation class, one subject, fixed local inputs, bounded outputs, and one checkable receipt. Stable subject IDs keep similarly named properties separate. Package-hash-derived idempotency keys prevent duplicate dispatch when the board is reconciled. Separate workspaces prevent one hotel from overwriting another. A machine-wide lock serializes memory-heavy local-model calls even when many entity workflows are otherwise active.

The same project → subject → packet pattern can eventually support restaurants and attractions, but those entity types still need their own official-source rules, source-family classifiers, corpus quotas, and extraction schemas. Reusing the orchestration shape does not mean pretending that all entities have identical evidence contracts.

Current status

The Omni production smoke test completed Step 1 with four validated local sources, three independent source families, zero source-hash errors, and two compiled extraction cards. The cards have not been dispatched yet. That is deliberate: the next qualification target is the quotation-extraction and deterministic-validation boundary described above.