Source: https://guthlabs.ai/docs/project-templates/apple-feature/deadlines/ project template / candidate # Apple platform feature โ€” deadlines The distinct deadlines record for Apple platform feature. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: project:apple-feature **Parent lifecycle**: candidate **Page lane**: app_features **Lane lifecycle**: proposed **Owner**: Not separately recorded **Owner role**: Not separately recorded **Owner status**: Not separately recorded **Qualification result**: NOT RUN ยท held for evidence and human review **Working browser surface:** [Project templates & workflows โ€” overview]() โ€” Create a local project from this template and validate its forms. This route is local-only; provider, credential, database, customer, publication, deployment, and production effects remain held. ## Deadline and workback rules - Every project must have a proposed target outcome date or explicitly state that the date is not yet known. - Every milestone must have an owner, planned finish date, predecessor or explicit no-predecessor declaration, and exit criteria. - Evidence capture and review deadlines must precede the approval deadline by a recorded review window. - A blocked milestone must have a blocking dependency, owner, next review date, and fallback or escalation note. - Changes to target dates or milestone dates must create a revision note and preserve the prior value. - Hard deadlines must not be silently moved; replanning requires an approval or held decision record. - A recurring to-do is only a candidate until a human reviews and confirms the recurrence. - External calendar, provider, credential, database, customer, publication, and production writes remain held unless separately verified. - Target qualification date is required before a qualification workback can be generated. - Every derived checkpoint must retain its source target date, offset, timezone, and revision. - Default workback offsets are proposals only and must be editable: evidence cutoff 2 business days before qualification, accessibility review 3 business days before qualification, device testing 5 business days before qualification, implementation complete 8 business days before qualification. - A checkpoint with no dueAt is shown as unscheduled, never silently assigned a date. - Past-due incomplete items are marked overdue; completed items retain their original dueAt and completion timestamp. - Changing the target date previews affected dates before saving and records a revision. - Conflicting or impossible dates are surfaced as a blocking validation error with the conflicting records named. - External calendar creation, reminders, messages, notifications, deployment, entitlement changes, and release publication remain held. ## Workback sequence - Create the project record with a canonical ID, owner, lifecycle, and target outcome. - Record the native platform, device families, OS range, capability or entitlement dependency, and simulator/device boundary. - Define in-scope behavior, explicit exclusions, accessibility requirements, privacy-sensitive data, and expected failure states. - Add source-labelled notes and local file references; preserve provenance, revisions, links, and attachments without implying upload or protected-storage completion. - Enter the qualification and release decision dates; generate workback to implementation, device testing, accessibility review, evidence cutoff, and approval checkpoints. - Create linked to-dos with dueAt, priority, tags, completion state, and review status. - Open the project in PointGuard to project current work, blockers, due items, linked records, and held decisions. - Run local interface, unit, device, failure-state, accessibility, and regression checks; attach or link evidence records. - Submit the qualification proposal for local approval; preserve the decision, reviewer, timestamp, and receipt. - Mark unresolved entitlement, provider, credential, publication, deployment, or production actions as Held rather than executing them. ## Scheduling records - milestone records - deadline and workback to-dos - dependency records - owner assignments - Implementation task records ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:project:apple-feature` - `NotebookCollectionKind.project` - `NotebookTodoPayload.dueAt` - `Notebook Agenda deadlines/workbacks` - `Notebook records canonical IDs, provenance, source locators, source SHA-256, revisions, lifecycle, tags, links, and attachments` - `PointGuard persistent cross-app context surface` - `APP_ROUTES:/app/notebook/projects/` - `APP_ROUTES:/app/notebook/to-dos/` - `APP_ROUTES:/app/notebook/agenda/` - `APP_ROUTES:/app/notebook/files/` - `APP_ROUTES:/app/notebook/approvals/` - `APP_ROUTES:/app/notebook/field-guides/` - `APP_ROUTES:/app/notebook/agent-logs/` - `APP_ROUTES:/app/pointguard/` - `Notebook records provenance and revision contract` - `Current GuthHub app routes and held external-effect boundary`