Guth
NewsDocs
Page actions
View as Markdown ↗
Explore MCP tools ↗

project template / candidate

Customer implementation — forms

The distinct forms record for Customer implementation. This page is proposal-only.

Status: proposedLifecycle: candidate

Record status

Record ID
project:customer-implementation
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

Identify the proposed customer implementation and establish the bounded context before work begins.

  • project title
  • customer name or internal label
  • customer context identifier
  • implementation owner
  • customer project owner
  • requested start date
  • target completion date
  • business purpose
  • desired outcome
  • requesting party
  • visibility classification
  • tenant boundary statement
  • effect isolation statement
  • known source records
  • intake notes
  • accessibility or accommodation needs

Scope

Define what is included, excluded, held, and subject to later approval.

  • in-scope capabilities
  • out-of-scope capabilities
  • target user groups
  • supported Guth surfaces
  • customer-specific configuration items
  • data or records to be referenced
  • customer data handling constraints
  • provider effects marked held
  • credential handling marked held
  • database authority marked held
  • publication or customer indexing marked held
  • qualification claims marked held
  • scope assumptions
  • scope acceptance owner
  • scope review date

Milestones

Create ordered deliverables with explicit owners, dates, acceptance evidence, and status.

  • milestone name
  • milestone description
  • sequence number
  • start date
  • due date
  • milestone owner
  • reviewer
  • required predecessor milestones
  • deliverable record type
  • expected evidence
  • approval required
  • status
  • completion notes
  • replan reason

Deadlines and Workback

Convert the target completion date into dated, reviewable workback tasks.

  • target completion date
  • deadline name
  • deadline type
  • due date and time
  • priority
  • recurrence candidate
  • completion state
  • task owner
  • reviewer
  • workback offset
  • predecessor task
  • tags
  • revision note
  • late-state handling
  • customer communication needed

Dependencies

Track internal, customer-provided, technical, review, and evidence dependencies without implying live connections.

  • dependency name
  • dependency type
  • description
  • blocking status
  • required-by milestone
  • dependency owner
  • provider or system reference
  • source record reference
  • expected availability date
  • verification method
  • fallback plan
  • escalation owner
  • resolution status
  • resolution evidence

Owners and Responsibilities

Make record ownership and review authority explicit.

  • project owner
  • implementation owner
  • customer owner
  • milestone owners
  • deadline owners
  • evidence custodian
  • approval reviewer
  • risk owner
  • closure reviewer
  • Agent operator if used
  • backup owner
  • responsibility notes
  • handoff date
  • handoff receipt

Workback Plan

Provide a deterministic sequence from approved scope to closure.

  • target outcome
  • final approval date
  • acceptance testing date
  • evidence freeze date
  • configuration review date
  • customer review date
  • draft completion date
  • dependency confirmation date
  • scope approval date
  • intake date
  • buffer days
  • calendar assumptions
  • replan trigger
  • replan owner

Tools and Guides

Declare the interfaces, skills, guides, records, or providers proposed for each step and preserve authority boundaries.

  • tool or surface name
  • tool kind
  • purpose
  • step using tool
  • canonical record owner
  • local prototype or indexed state
  • provider effect status
  • credential requirement status
  • guide reference
  • fallback surface
  • operator notes
  • authority boundary acknowledged

Evidence and Receipts

Capture source-bound evidence for decisions, configuration, tests, and handoffs.

  • evidence title
  • evidence type
  • related milestone
  • source record identifier
  • source locator
  • source SHA-256 if available
  • provenance note
  • attachment or local file reference
  • capture date
  • captured by
  • revision identifier
  • visibility
  • evidence status
  • receipt description
  • missing-evidence reason

Approvals

Record human review of scope, configuration, acceptance, communications, and closure.

  • approval subject
  • approval type
  • proposed decision
  • reviewer
  • review status
  • decision date
  • decision notes
  • conditions
  • receipt reference
  • rejection reason
  • held action
  • next review date

Risks and Failure States

Identify conditions that could block, misconfigure, expose, or falsely represent the implementation.

  • risk title
  • risk category
  • description
  • likelihood
  • impact
  • severity
  • owner
  • mitigation
  • contingency
  • trigger
  • affected milestone
  • status
  • escalation path
  • residual risk acceptance
  • review date

Closure

Confirm whether the bounded implementation is complete, held, cancelled, or requires follow-up.

  • closure status
  • completion date
  • acceptance summary
  • open items
  • unresolved risks
  • handoff owner
  • handoff receipt
  • customer review status
  • evidence completeness
  • approval completeness
  • held production effects
  • follow-up deadlines
  • lessons learned
  • closure reviewer
  • closure decision notes

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 and scope

Define the project and prevent cross-customer mixing.

  • project title
  • customer display name
  • tenant or workspace label
  • implementation owner
  • project status
  • scope statement
  • out-of-scope statement
  • visibility setting
  • tags

Target outcome

Describe the bounded configuration outcome without implying deployment.

  • desired product configuration
  • success evidence required
  • acceptance owner
  • target completion date
  • assumptions
  • known blockers

Milestones and workback

Create explicit deadlines and predecessor relationships.

  • milestone name
  • milestone owner
  • due date and time
  • priority
  • estimated effort
  • predecessor task IDs
  • review buffer
  • recurrence candidate
  • completion state

Evidence and linked records

Attach source-labelled references and preserve record ownership.

  • linked notebook record IDs
  • file reference IDs
  • source locator
  • source SHA-256 if available
  • provenance note
  • record lifecycle
  • link relationship

External effects and approvals

Make provider, credential, publication, customer, and production effects visibly held.

  • proposed effect description
  • affected surface
  • required reviewer
  • approval state
  • draft message ID
  • execution receipt placeholder
  • hold reason

Required or proposed record references

No record existence is asserted by this documentation page.

  • Project record
  • Customer context record
  • Scope decision record
  • Milestone records
  • Deadline and workback todo records
  • Dependency records
  • Owner assignment records
  • Tool and guide selection records
  • Evidence and receipt records
  • Approval records
  • Risk records
  • Closure record
  • Project record with canonical ID, lifecycle, origin, provenance, revision, tags, links, and tenant-isolation label
  • Customer context record with non-sensitive display name and explicit scope boundary
  • Implementation milestone to-do records with dueAt, priority, completion state, tags, and revisions
  • Workback dependency records linking tasks to a target deadline
  • Source-labelled file reference records
  • Draft message records with recipient and send-held state
  • Approval records for proposed configuration or effect
  • Agent log records for any bounded assistance
  • PointGuard projection record identifying current project, next actions, blockers, and held effects

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

  • source_record:project:customer-implementation
  • NotebookCollectionKind.project
  • NotebookTodoPayload.dueAt
  • Notebook Agenda deadlines/workbacks
  • Observed native contract: project_and_field_guide_collections
  • Observed native contract: deadlines
  • Observed native contract: records
  • Observed native contract: pointguard
  • Observed native contract: web_boundary
  • /app/notebook/projects/
  • /app/notebook/to-dos/
  • /app/notebook/agenda/
  • /app/notebook/approvals/
  • /app/notebook/files/
  • /app/notebook/field-guides/
  • /app/notebook/agent-logs/
  • /app/pointguard/
  • project:customer-implementation
  • Observed native contract: records preserve canonical IDs, provenance, revisions, 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
  • Observed native contract: provider, credential, database, customer, publication, and production effects are held