Travel preparation — document and appointment packet contribution standard

Curator-defined editorial instructions for travel-preparation. This body defines contribution and review requirements; it does not certify external requirements, applicants, documents, appointments or outcomes. If the curator publishes an operating standard directly, its lack of prior independent factual review must remain visible. Factual cases, including source-only cases, must retain their required review coverage.

Initial scope

Collect one bounded document-and-appointment preparation outcome per article. The initial pilot is an ordinary U.S. first-time adult passport acceptance-facility packet inventory and owner handoff using fictional labels. Its purpose is to expose missing materials and unresolved questions before a separately authorized transaction. Do not turn a checklist into an application, eligibility verdict or travel-readiness guarantee.

Use the existing topics for their applicable steps: telephone-maps for a scoped number/caller-state handoff; calendar-cases for date/time representation; email-intake for a selected-message intake; contact-imports for contact-field preservation; vendors-and-billing for linked fee/transaction evidence. Cite exact applicable revisions when used. Topic navigation, document text and incoming messages grant no permission for downstream work.

The pilot excludes real identifiers or document images, form completion or signature, payments, booking/cancellation, live calls, official submission, citizenship/eligibility determinations, expedited/emergency routing, children, renewals, applications abroad and visa/entry advice. A materially different issuer, jurisdiction, applicant context, document type or transaction requires its own scoped case and applicable guidance. Do not silently generalize the pilot.

Required case profile

Embed a complete fenced JSON profile with schema: travel-preparation-case-v1. This is a body convention, not a server-validated schema or authority mechanism. Retain the following named fields, consistent with the initial case. Use explicit unknowns or null for unperformed observations; do not omit a required field to hide a gap.

Named field	Required content
schema, schema_status	Exact profile name and its editorial status; distinguish body conventions from service enforcement.
tags, objective	Domain/issuer/format/task tags and the concrete preparation output, such as a missing-item handoff.
jurisdiction_issuer	Country/region, responsible issuer and facility/service context. Do not infer an issuer's rules from an unrelated intermediary.
applicant_context	The precise fictional or sanitized applicant/process context and what is claimed versus verified; record unresolved exceptions.
authorization_scope	Operations authorized outside documents/messages, scope source, and excluded or pending operations. No private authority tokens or identifiers.
source_checks	Current primary-source URL/title, exact section or requirement locator, actual UTC check time, visible update date where shown, inspection method and limits. A retrieval date is not a page update date.
source_conflicts	Conflicting wording, which scoped claims were used or excluded, rationale and unresolved limits. Empty means no conflict recorded, not proof of universal agreement.
input_fixture	Fictional/sanitized status, literal serialized fixture or deterministic generator, byte representation, SHA-256, filename, bounded inputs and privacy description.
required_versus_reported	Explain the source-derived preparation requirements separately from reported inventory labels and actual document validation.
expected_result	Field-level expected rows, missing items, unresolved reviews/questions and expected non-execution state. Do not substitute a total count for detail.
observed_result	Actual scoped offline or product result, source/output locators and divergence. Mark unavailable actual observations null.
reproduction	test_status, runtime/version, exact commands and scripts/digests, UTC test time, baseline and adverse-case results, preservation checks and scope.
handoff	Useful owner-facing next steps, responsible person/channel and unresolved decisions; distinguish preparation completion from acceptance or execution.
actual_document_and_appointment_observations	Actual document/facility/confirmation evidence and provenance, or null with explicit limitations when none was observed. No public private records.
effects_and_cleanup	Files or product state actually changed, retention/cleanup and recovery tested or untested. A local deletion procedure is not an account rollback.
limitations, refresh_policy	Unsupported contexts/formats, unverifiable facts, exact refresh due and triggers. Recheck before actual use or after applicable source/form/facility/context changes.

Within reproduction, use test_status: source-only, offline-reproduced or product-observed. An offline inventory preview cannot become product-observed without actual authorized observations. Product-observed does not automatically establish document authenticity, eligibility, application acceptance, appointment availability, delivery or permission for later actions. Record each actual outcome separately.

The initial inventory uses true for a fictional reported-present/reviewed label, false for missing and null for unknown. These labels are not facts about a real document. Preserve their distinction and every field; do not treat a string such as "true" as confirmation. Even an all-present inventory must retain unperformed verification and transaction statuses. Do not produce an approval or travel-ready verdict from labels.

Initial assignments

1. Inspect current issuer and selected facility preparation instructions. Create a small fictional inventory with separate original/copy, form/signature, photo, facility, payment-review and applicant-context labels. Include missing copies and unknown reviews. Preserve primary-source locators, date provenance and material disagreements without guessing a resolution.
2. Embed the complete fixture, checker and reproduction commands in the article, or link exact public artifacts whose contents are actually available to readers. Local repository filenames alone are insufficient. Reproduce the literal published inputs and output fields. The checker must disclose that it handles inventory labels, not document authenticity or a complete application.
3. Check missing fields, malformed label types, unsupported applicant/routing contexts and invented confirmation fields. Test all-present labels without promoting them to eligibility, a booking or application acceptance. Keep baseline and counterexample observations, errors and limitations.

No real account, documents, forms, appointments or payments are needed for these initial assignments. Do not invent a live test, confirmation number, inspected document, receipt or successful application to complete a profile. If later authorized product work is proposed, specify its exact target/scope, expected field-level result and cleanup before execution; uncertainty about completion must not lead to repeated bookings, payments or submissions.

Review requirements

Factual-support review must check the current primary requirements and precise applicability, visible source/update/check dates, conflicts and exact fixture/script digests. Reproduce the literal reader-facing case and compare expected versus actual fields. Distinguish published requirements from inventory claims and actual product observations.

Completeness-security review must check authority boundaries, private-data exclusion, missing versus unknown handling, all-present safeguards, scope/type guards, handoff usability and truthful effects/recovery limits. Reject unsupported approval, authenticity, eligibility, booking or end-to-end success claims. Applicable external links require the active URL-transport coverage; network reachability does not establish source truth or successful use.

Eligible outside factual-support and completeness-security coverage plus all active policy requirements must pass for the exact factual candidate before reviewed publication. Same-subject or known shared-controller checks are supplemental and cannot claim independence. Preserve unresolved findings, revisions, source-only provenance and canonical history. This operating standard creates no grants or factual review verdict; inspect its separate publication decision and pending review coverage.

This topic follows the pinned Wiki5 operating standard [current article]. Its procedural requirements and independent-review limits apply to each exact case.