Source: https://guthlabs.ai/docs/field-guides/ipados-27/steps/ field guide / candidate # iPadOS 27 โ€” steps The distinct steps record for iPadOS 27. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: field-guide:ipados-27 **Parent lifecycle**: candidate **Page lane**: plan **Lane lifecycle**: proposed **Owner**: Tim **Owner role**: Not separately recorded **Owner status**: Not separately recorded **Qualification result**: NOT RUN ยท held for evidence and human review **Working browser surface:** [Field guides โ€” documentation]() โ€” Inspect the guide and persist local checkpoints. This route is local-only; provider, credential, database, customer, publication, deployment, and production effects remain held. ## Ordered procedure - Create a proposed field-guide record owned by Tim and link the supplied source record, related jobs, and this guide. - Create a Notebook project for the iPadOS 27 investigation; set membership ordering so source intake precedes hypotheses, validation tasks, and decisions. - Write a bounded investigation question that distinguishes platform discovery from implementation, deployment, provider connection, database authority, customer indexing, publication, or qualification. - Collect source-labelled notes and file references only from supplied records or later verified material; preserve canonical ID, origin, locator, SHA-256, provenance, revision, lifecycle, tags, links, and attachments. - For each candidate capability, create a hypothesis record containing the exact observed statement, source locator, expected user value, required behavior, unknowns, and explicitly held effects. - Map each hypothesis to the relevant Guth specialist surface. Use PointGuard only as a persistent context surface; keep execution and canonical-record ownership with the named specialist app. - Define a small validation task for each hypothesis, including prerequisites, owner, due date, review state, evidence required, and a deterministic acceptance test. - Use Notebook To-dos and Agenda to stage the workback. Treat due dates, recurrence candidates, schedule changes, and external writes as local drafts or human-held decisions. - Review accessibility before recommending any prototype: keyboard and pointer reachability, readable labels, focus order, non-color status cues, and an equivalent path for users who cannot use a particular interaction mode. - Run the validation checklist against the available source and observed contract. Record pass, fail, blocked, or unknown; do not convert a named native surface into evidence of a connected web feature. - Submit the decision record for review in Approvals. Preserve the proposal, evidence links, unresolved risks, and receipt whether the decision is approved locally, held, or rejected. - If a hypothesis survives review, create a separate implementation proposal owned by the relevant specialist app. Keep the field guide at proposed status until verified behavior and authority boundaries are independently established. ## Deadline and chronology rules - Set an intake deadline before creating capability hypotheses. - Assign each hypothesis a validation deadline and a named owner. - Schedule a review deadline after evidence capture and before any implementation recommendation. - If evidence is missing, mark the task blocked and set a follow-up deadline rather than treating the hypothesis as passed. - Do not set a publication, provider-write, customer-indexing, deployment, or production-qualification deadline because those effects are held by the observed contract. ## Failure branches during execution - Confusing the iPadOS 27 title or related job names with verified platform behavior. - Treating a named native surface as evidence that a connected web feature exists. - Inferring SwiftUI, App Intents, Spotlight, or cross-device behavior not present in the supplied source record. - Assigning canonical ownership to PointGuard instead of the specialist app. - Creating doorway documentation URLs with no distinct useful content. - Losing source locators, hashes, provenance, or revisions when copying evidence. - Scheduling external writes, provider actions, publication, customer indexing, or deployment as if they were available. - Using unsupported claims as acceptance evidence. - Skipping accessibility or failing to provide a non-gesture or non-color equivalent. - Allowing an Agent proposal to bypass human review or approval receipts. ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:field-guide:ipados-27` - `agents/index.html#tim` - `source record field-guide:ipados-27:plan` - `Observed native contract: project_and_field_guide_collections` - `Observed native contract: deadlines` - `Observed native contract: records` - `Observed native contract: pointguard` - `App route /app/notebook/field-guides/` - `App route /app/pointguard/` - `App route /app/notebook/approvals/` - `App route /app/notebook/agent-logs/`