Source: https://guthlabs.ai/docs/project-templates/customer-indexing/forms/ project template / candidate # Customer indexing โ€” forms The distinct forms 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**: forms **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. ## Proposed form sections Each section is a candidate schema for inspectable records. Required-field presence does not establish factual truth. ### Intake and authorization Capture the request, requester, intended audience, and consent boundary before any crawl or indexing work is proposed. - request title - requester name or team - project owner - business purpose - intended audience - customer or site identifier - authorized domains and URL patterns - authorization basis and consent reference - private-content exclusions - prohibited paths, parameters, and file types - visibility classification - requested start date - requested completion date - success statement - out-of-scope statement ### Scope and boundary Define deterministic inclusion and exclusion rules without implying access or execution. - in-scope URL patterns - out-of-scope URL patterns - robots or policy reference supplied by requester - authentication-required areas marked held - personal, private, or customer-only content exclusions - crawl depth limit - content types allowed - content types excluded - duplicate and canonicalization rules - language or locale scope - index fields proposed - retention and deletion rule - human review checkpoints ### Milestones and deliverables Break the work into reviewable stages with owners, dates, evidence, and exit criteria. - milestone name - milestone description - owner - reviewer - planned start - planned finish - status - deliverable - entry criteria - exit criteria - evidence required - approval required - blocking condition ### Deadlines and workback Record due dates, priorities, recurrence candidates, completion state, and revisions using the native todo contract. - deadline title - dueAt - priority - recurrenceCandidate - completion state - tags - revision note - dependency links - buffer days - missed-deadline response - scheduled view - deadline view ### Dependencies and handoffs Expose prerequisites and ownership transfers before a milestone can begin. - dependency description - dependency type - blocking milestone - source or owning record - dependency owner - required-by date - state - verification evidence - fallback or escalation - handoff recipient ### Owners and authority Make responsibility and authority boundaries explicit for every project activity. - project owner - scope owner - technical reviewer - privacy or consent reviewer - evidence custodian - approval owner - closure owner - agent role if proposed - human-only decisions - authority denied or held - backup owner - contact or PointGuard room reference ### Workback plan Create a reverse schedule from the proposed completion date with buffers and review gates. - target completion date - workback anchor - task sequence - task duration - predecessor - owner - review buffer - evidence checkpoint - approval gate - critical-path flag - date-change rationale - revised baseline ### Tools and guides Name only observed native surfaces and verified instruments that may support planning or review; execution and canonical ownership remain with specialist apps. - tool or guide name - kind - route - proposed use - record owner - authority boundary - fallback - instrument slug if applicable ### Evidence and provenance Preserve source-labelled proof for scope, decisions, tests, and approvals. - evidence title - evidence type - source locator - source SHA-256 if available - captured by - captured at - related milestone - related decision - visibility - attachment or local file reference - provenance note - revision ### Approvals and holds Record human decisions before scope changes, external communication, or any held effect. - approval request - decision owner - submitted at - decision state - decision rationale - scope version - evidence links - conditions - expiry or re-review date - receipt reference - external send required flag - production effect held confirmation ### Risks and failure states Track privacy, scope, scheduling, accessibility, evidence, and authority failures with mitigations. - risk title - category - description - likelihood - impact - severity - trigger - owner - mitigation - contingency - status - review date - residual risk - stop-work condition ### Closure and handoff Close the proposal with evidence completeness, unresolved issues, retention action, and explicit non-execution status. - closure owner - closure date - outcome - deliverables reviewed - acceptance results - open risks - unresolved dependencies - evidence completeness - records to retain - records to delete or hold - handoff recipient - follow-up date - closure approval - external effects remain held confirmation ### Accessible state contract - Every field requires a visible and programmatic label. - Required and optional fields must be stated in text. - Invalid entries require an actionable message linked to the field. - Blocked and Held states remain visible without relying on color alone. ## Supporting documentation fields These fields come from the app_features lane and remain separate from the primary operating form. ### Project identity Establish ownership and a durable local project record. - project title - short purpose - owner - reviewers - project lifecycle - tags - notes ### Consent and scope Make authorization and boundaries explicit before any crawl plan is staged. - customer or organization name - supplied website URL - consent status - consent evidence record link - allowed domains - allowed path prefixes - excluded paths or content classes - private-content handling rule - scope expiration date - scope reviewer ### Crawl plan Define a reviewable, non-executing plan with deterministic limits. - planned entry points - proposed page types - robots and access notes - maximum pages - maximum depth - request pacing note - session or credential requirement - stop conditions - failure handling - manual review checkpoints ### Index design Specify what may be indexed without exposing private content. - proposed indexed fields - excluded fields - public/private classification - redaction rule - retention note - duplicate handling - source locator requirement - proposed visibility state ### Deadlines and workback Turn review gates into accountable local work. - target review date - consent verification due date - scope approval due date - crawl-plan review due date - index-field review due date - export or handoff due date - task owner - priority - recurrence candidate - blocking dependency ### Evidence and receipts Keep source-labelled references and decisions attached to the project. - linked Notebook records - local file references - source locators - source SHA-256 where available - decision receipt - revision note - held-effect explanation ## Required or proposed record references No record existence is asserted by this documentation page. - project record - scope record - milestone records - deadline and workback to-dos - dependency records - owner assignments - tool and guide links - evidence records - approval records - risk records - closure record - project record with canonical ID, lifecycle, provenance, source references, revision history, tags, and links - customer-scope record containing supplied domain or URL, consent status, scope boundaries, exclusions, and review owner - crawl-plan record containing proposed paths, robots and access notes, rate limits, stopping conditions, and failure policy - index-field record identifying proposed searchable fields and private-content exclusions - deadline to-do records with dueAt, priority, completion state, tags, and revisions - source-labelled file references for consent evidence or review material - approval records for scope, crawl readiness, index-field design, and any proposed export ## 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`