Source: https://guthlabs.ai/docs/project-templates/operations-migration/qualification/ project template / candidate # Operations migration โ€” qualification The distinct qualification record for Operations migration. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: project:operations-migration **Parent lifecycle**: candidate **Page lane**: qualification **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. ## Qualification status **Result**: NOT RUN **Disposition**: HELD **Reviewer**: Not recorded **Receipt**: Not recorded This page defines proposed acceptance criteria for the qualification lane. It does not execute tests, establish compliance, qualify the subject, or authorize an effect. ### Lane-specific instrument aids No verified instrument is assigned to this qualification lane. ## Outcome definitions **Verified**: All stated evidence and acceptance requirements passed for the exact reviewed revision; this still does not authorize deployment or an external effect. **Failed**: One or more deterministic acceptance requirements failed with an inspectable reason. **Needs review**: Evidence or interpretation is incomplete, conflicting, or awaits an identified human reviewer. **Held**: Authority, required evidence, safe execution conditions, or a principal gate is absent. The current record remains NOT RUN / HELD. These definitions describe candidate outcomes only. ## Proposed deterministic acceptance tests Route-resolution and distinct-content checks apply only to the admitted canonical routes in this record. Held source-proposed extensions are non-resolving proposals and are excluded. - A submission with no project owner, migration lead, approver, scope, or success definition is rejected with field-level errors. - A submission with an end date or gate date lacking date, time, or timezone is rejected. - A dependency without an owner, required-by date, blocking status, and evidence or stated exception is rejected. - A workback with reconciliation scheduled before rehearsal is rejected. - A proposal without a deterministic matching key, population definition, comparison rule, accepted variance, and unmatched-item rule is rejected. - A proposal without rollback trigger, rollback owner, rollback steps, and verification evidence is held. - Any cutover proposal with unresolved blocking dependencies or unreconciled exceptions is held. - Changing a deadline or reconciliation rule creates a new revision and preserves the previous revision as read-only history. - Duplicate submissions with the same canonical project ID and revision token do not create a second authoritative record; the conflict is surfaced for review. - A failed save or unavailable local surface leaves the form data recoverable where supported, reports the failure clearly, and does not display a successful-save state. - An approval action records reviewer, timestamp, decision state, changed revision, and receipt; it does not send messages, write providers, alter databases, or perform cutover. - A rejected or held proposal remains searchable only according to its visibility classification and is not treated as qualified. - Keyboard-only review reaches every field, error, gate, and destructive action in logical order. - Every error is associated with its field, announced to assistive technology, and described without relying on color alone. - Comparison results expose text alternatives for counts, mismatches, duplicates, and exceptions; no meaning is conveyed only through visual styling. - Sensitive fields are minimized, redaction is available before saving, and private records are excluded from public indexing. - Delete, discard, clear, or rollback-plan replacement requires an explicit confirmation naming the affected record and consequence. - A destructive action is disabled or held when the actor lacks recorded authority or when a newer revision exists. - If reconciliation cannot be completed, the system records the failure state, preserves inputs and evidence links, assigns an owner, and prevents approval. - If rollback verification fails, the project enters held state with an escalated exception and cannot be marked qualified. ## Negative and held-state tests - Treating local prototype routes as connected migration systems or production control planes. - Assuming provider, credential, database, customer, publication, or cutover effects from a named surface. - Silent deadline timezone conversion or ambiguous date interpretation. - Approving incomplete reconciliation because counts happen to match. - Loss of revision history when assumptions, dependencies, or dates change. - Duplicate records or conflicting edits creating unclear ownership. - Exposing operationally sensitive data through search, attachments, public context, or incorrect visibility labels. - Using inaccessible visual comparison evidence that prevents an authorized reviewer from detecting exceptions. - Destructive deletion or rollback-plan replacement without confirmation, authority, or recovery evidence. - Failure states being presented as success after save, reconciliation, approval, or rollback operations. - Overstating qualification, readiness, deployment, provider connection, or rollback safety. ## Qualification claim boundary ### Potentially allowed only after the stated evidence - A proposed project template can define migration scope, ownership, deadlines, dependencies, reconciliation rules, revision controls, privacy expectations, accessibility requirements, and rollback evidence requirements. - The observed Notebook contract supports project collections, lifecycle, ordering, due items, revisions, provenance, links, attachments, and held provider effects. - Local prototype routes can be designated as review surfaces for proposal records and workbacks. ### Still held - The capability has not been migrated or qualified. - No provider, credential, database, customer, publication, or production connection is established. - No cutover, rollback, external write, message send, or operational change has occurred. - No reconciliation result, approval, deployment, or production readiness is asserted. - Named native surfaces do not prove a connected web feature or authoritative backend. ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:project:operations-migration` - `NotebookCollectionKind.project` - `NotebookTodoPayload.dueAt` - `Notebook Agenda deadlines/workbacks` - `Notebook records preserve canonical IDs, provenance, revisions, lifecycle, tags, links, and attachments` - `PointGuard persistent cross-app context surface with specialist apps as execution and canonical-record owners` - `Current GuthHub app routes are local prototypes or indexes; provider, credential, database, customer, publication, and production effects are held`