Research study — qualification

Record status

Record ID

project:research-study

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.

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.

• Submitting without a research question, owner, scope boundary, or decision date is rejected with field-level errors and no partial qualification record.
• A valid submission creates one canonical project record and preserves origin, provenance, lifecycle, revision, and linked-record relationships.
• Whitespace-only text, invalid dates, reversed workback dates, duplicate milestone IDs, and unsupported lifecycle values are rejected deterministically.
• A source claim cannot be accepted without a source locator, provenance, claim text, and link to the project.
• A contradiction record must identify both claims or sources and cannot be resolved by deletion or overwrite; resolution creates a revision receipt.
• The decision cannot move to Approved while required evidence, citation audit, contradiction review, or mandatory milestones are incomplete.
• Held claims remain excluded from accepted claims and are visible in the decision rationale and limitations.
• Editing scope, criteria, evidence, deadlines, or decision status creates a revision and does not mutate the prior revision invisibly.
• Keyboard-only operation reaches every field, error, status, disclosure, and destructive-action control in logical order.
• Every validation error is associated with its field, stated in text, announced to assistive technology, and remains visible until corrected.
• Color is not the sole indicator of overdue, disputed, held, approved, or failed states; each state has text and accessible semantics.
• Labels, instructions, focus indicators, headings, table relationships, and status announcements remain usable at zoom and reflow without requiring a pointer.
• Private or held records are excluded from public or unsupported search contexts; search results expose visibility and source labels.
• No form action sends a message, publishes a document, exports a result, writes to a provider, changes a customer record, or claims production qualification.
• Deleting a project, source, claim, contradiction, or approval requires explicit target identification, confirmation, and a reversible hold or documented tombstone; cancellation causes no change.
• If save, indexing, scheduling, or approval preparation fails, the interface preserves entered values locally where possible, identifies the failed operation, offers retry, and does not display success.
• If a linked record is missing, inaccessible, superseded, or malformed, the project is marked blocked or held with the dependency named; it is not silently detached.
• If a deadline conflict or stale revision is detected, the system prevents overwrite, shows the conflicting revision, and requires an explicit rebase or new revision.
• If an Agent lacks authority, source access, or a required receipt, the task remains Held or Needs review and records the reason without retry loops or implied completion.
• A final approval receipt names the approver, decision status, reviewed revision, evidence scope, unresolved limitations, and timestamp.
• A qualification decision remains proposal-only; no acceptance test may treat an approved local record as deployment, provider connection, publication, customer indexing, database authority, or production state.

Negative and held-state tests

• Unbounded research scope can produce late or non-reproducible conclusions.
• Citation laundering, stale sources, missing locators, and unsupported summaries can make claims appear better supported than they are.
• Contradictory evidence may be collapsed, deleted, or hidden during revision.
• Deadline drift, timezone ambiguity, recurrence candidates, and agenda conflicts can create false scheduling certainty.
• Private source material may leak through search, PointGuard context, attachments, or public documentation routes.
• Accessibility failures can prevent keyboard, screen-reader, zoom, reflow, or low-vision users from completing review.
• Destructive deletion or overwrite can destroy provenance, contradiction history, or approval receipts.
• A native route or named surface may be mistaken for a connected provider, database, publication, or production feature.
• Agent output may be mistaken for human verification or authority.
• Partial saves and stale revisions can create duplicate projects, orphaned evidence, or false completion states.

Qualification claim boundary

Potentially allowed only after the stated evidence

• This is a proposed bounded research-study project template.
• The template defines source-backed claims, contradiction controls, citation review, workback deadlines, human approval, and held failure states.
• The observed native contract includes local prototype or index surfaces for projects, notes, files, to-dos, agenda, approvals, search, and Agent logs.
• Provider, credential, database, customer, publication, export, and production effects are explicitly held.

Still held

• Do not claim the study is deployed, connected, qualified in production, published, exported, customer-indexed, or backed by a live database.
• Do not claim any provider, calendar, storage, search, Agent, or approval integration is connected.
• Do not claim source completeness, factual correctness, human approval, or final qualification before a recorded review receipt.
• Do not claim distinct documentation pages are published or that any route is more than a local prototype or index without verified behavior.

Sources and evidence

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

• source_record:project:research-study
• NotebookCollectionKind.project
• NotebookTodoPayload.dueAt
• Notebook Agenda deadlines/workbacks
• Notebook records: canonical IDs, origin, source locators, source SHA-256, provenance, revision, lifecycle, tags, links, attachments, and record revisions
• PointGuard persistent cross-app context surface; specialist apps remain execution and canonical-record owners
• /app/notebook/projects/
• /app/notebook/notes/
• /app/notebook/files/
• /app/notebook/to-dos/
• /app/notebook/agenda/
• /app/notebook/approvals/
• /app/notebook/search/
• /app/notebook/agent-logs/
• /app/pointguard/