Source: https://guthlabs.ai/docs/project-templates/customer-indexing/deadlines/ project template / candidate # Customer indexing โ€” deadlines The distinct deadlines record for Customer indexing. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: project:customer-indexing **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 milestone and blocking dependency must have an explicit owner and required-by date. - Every due date must include a timezone or an explicit timezone-unknown state. - A workback must include at least one review buffer before the target completion date. - A missed deadline moves the affected item to Needs review and records a revised date and rationale. - No deadline may authorize crawling, indexing, publication, provider access, credential use, or customer communication. - Recurring tasks require human confirmation before recurrenceCandidate is accepted. - Date changes require a revision note and preserve the prior baseline. - A project cannot enter local approval-ready state unless consent status is recorded and missing evidence is explicitly flagged. - Scope expiration must be earlier than or equal to any proposed crawl or handoff date; expired scope blocks readiness. - Index-field review must be due before any proposed export or handoff deadline. - Each blocking review must have an owner, dueAt, priority, and linked record. - Overdue items appear in Today and PointGuard with an explicit overdue label; no silent rescheduling occurs. - Workback dates are calculated locally from the target review date and declared dependencies; edits create revisions. - Recurring tasks are only suggestions and require human confirmation before creation. - Conflicting deadlines show both records and require a human resolution; the app must not choose silently. ## Workback sequence - Create the project record and assign an owner. - Record the supplied website URL and consent status; do not treat a URL as proof of authorization. - Attach or link consent evidence if available and mark missing evidence as a blocking condition. - Define allowed domains, path prefixes, exclusions, private-content rules, and scope expiration. - Draft crawl limits, stopping conditions, failure handling, and review checkpoints without initiating a crawl. - Define proposed index fields and explicitly exclude credentials, private content, session data, and unsupported claims. - Create deadline and workback to-dos with dueAt, priority, dependencies, and human owners. - Submit scope and index design for local approval; preserve approval, hold, or rejection receipts. - Project a PointGuard room containing current blockers, next deadline, linked records, and approval state. - If approved locally, prepare a held handoff package; do not connect providers, use credentials, crawl customer systems, write a database, publish an index, or claim qualification. ## Scheduling records - milestone records - deadline and workback to-dos - dependency records - owner assignments - customer-scope record containing supplied domain or URL, consent status, scope boundaries, exclusions, and review owner - deadline to-do records with dueAt, priority, completion state, tags, and revisions ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:project:customer-indexing` - `NotebookCollectionKind.project` - `NotebookTodoPayload.dueAt` - `Notebook Agenda deadlines/workbacks` - `Observed native contract: records preserve canonical IDs, origin, source locators, source SHA-256, provenance, revision, lifecycle, tags, links, attachments, and record revisions` - `Observed native contract: PointGuard is a persistent cross-app context surface and specialist apps remain execution and canonical-record owners` - `App route: /app/notebook/projects/` - `App route: /app/notebook/to-dos/` - `App route: /app/notebook/agenda/` - `App route: /app/notebook/approvals/` - `App route: /app/notebook/files/` - `App route: /app/notebook/field-guides/` - `App route: /app/notebook/agent-logs/` - `App route: /app/notebook/search/` - `App route: /app/pointguard/` - `Notebook record provenance and revision contract` - `PointGuard persistent cross-app context surface` - `Current GuthHub local prototype and index routes` - `customer-indexing project source record`