Customer indexing — deadlines

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

1. Create the project record and assign an owner.
2. Record the supplied website URL and consent status; do not treat a URL as proof of authorization.
3. Attach or link consent evidence if available and mark missing evidence as a blocking condition.
4. Define allowed domains, path prefixes, exclusions, private-content rules, and scope expiration.
5. Draft crawl limits, stopping conditions, failure handling, and review checkpoints without initiating a crawl.
6. Define proposed index fields and explicitly exclude credentials, private content, session data, and unsupported claims.
7. Create deadline and workback to-dos with dueAt, priority, dependencies, and human owners.
8. Submit scope and index design for local approval; preserve approval, hold, or rejection receipts.
9. Project a PointGuard room containing current blockers, next deadline, linked records, and approval state.
10. 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