iPadOS 27 — steps

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

1. Create a proposed field-guide record owned by Tim and link the supplied source record, related jobs, and this guide.
2. Create a Notebook project for the iPadOS 27 investigation; set membership ordering so source intake precedes hypotheses, validation tasks, and decisions.
3. Write a bounded investigation question that distinguishes platform discovery from implementation, deployment, provider connection, database authority, customer indexing, publication, or qualification.
4. 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.
5. 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.
6. 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.
7. Define a small validation task for each hypothesis, including prerequisites, owner, due date, review state, evidence required, and a deterministic acceptance test.
8. 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.
9. 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.
10. 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.
11. 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.
12. 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/