Learning course — qualification

Record status

Record ID

project:learning-course

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 non-empty title, owner, purpose, or source-reference state is rejected with field-level errors and no partial project record.
• Lesson order must be a unique positive integer; duplicate, missing, negative, or non-numeric order values are rejected deterministically.
• A lesson objective, source-link state, uncertainty marker, and prerequisite declaration must be present before the lesson can be marked ready.
• A source-linked lesson must reference an existing local record ID; an invalid, inaccessible, or missing ID yields a held dependency error rather than a fabricated link.
• Due dates must parse as valid calendar dates with timezone; invalid dates, ambiguous local times, and impossible dates are rejected.
• A dependent task cannot be completed while a prerequisite task is incomplete; the interface identifies the blocking record IDs.
• Changing a lesson objective, source link, prerequisite, or due date creates a new revision, preserves the prior revision, records the actor and reason, and does not overwrite provenance.
• A schedule conflict displays both records, the conflict type, and a Needs review state; no conflict is silently resolved.
• Keyboard-only navigation reaches every field, control, error, dialog, and destructive-action confirmation in logical order.
• Every input has a programmatic label; validation errors are associated with the relevant field and announced without relying on color alone.
• Status, uncertainty, priority, and completion states remain distinguishable through text or accessible labels in addition to color or iconography.
• Text, controls, focus indicators, and error messages remain usable at increased text size and reflow without loss of information or interaction.
• Private notes, source locators, attachments, and learner accommodation notes are excluded from shared-local views unless explicitly permitted by the owner.
• A user without edit authority cannot alter project structure, deadlines, provenance, visibility, or revisions and receives a non-destructive authorization error.
• Export, external send, provider connection, publication, and customer-facing indexing controls are visibly held and cannot claim completion.
• Deleting a lesson, source link, or project requires an explicit confirmation naming the affected record IDs, dependencies, attachments, and revisions; cancel leaves all records unchanged.
• A destructive action is rejected when the user lacks authority, the target is missing, or dependent records exist without an explicit dependency-resolution choice.
• Retrying a failed save does not duplicate canonical records, tasks, revisions, or receipts; idempotent retry preserves the original result.
• If a save, schedule calculation, or link resolution fails, the interface preserves entered data locally where supported, identifies the failed operation, and leaves the record in held or draft state.
• Uncertainty markers are preserved through revisions and cannot be converted to verified or complete without an explicit human action and receipt.
• Search results exclude private or held records from unauthorized contexts and expose source labels and lifecycle state for records that are visible.
• A completion proposal requires all required lessons, prerequisites, evidence fields, and unresolved uncertainty disclosures to be reviewed; otherwise it remains Needs review or Held.
• All local changes produce inspectable provenance and revision receipts containing canonical record ID, origin, source references, lifecycle, and change reason.

Negative and held-state tests

• A proposed course could be mistaken for an accredited qualification or published curriculum.
• Missing or weak source links could create unsupported lesson claims.
• Automatic workbacks could conceal timezone, calendar, dependency, or accessibility constraints.
• Learner accommodation notes may contain sensitive information and require strict visibility controls.
• A lesson revision may invalidate dependent tasks or previously recorded completion evidence.
• A failed save or retry could create duplicate lessons or deadlines without idempotency.
• Color-only status indicators could hide uncertainty, blocking conditions, or validation errors.
• Provider, publication, export, messaging, or customer effects could be inferred from named prototype surfaces.
• Deleting a source record could orphan lessons, evidence, attachments, and revisions.
• An instrument estimate could be mistaken for authoritative duration or qualification evidence.

Qualification claim boundary

Potentially allowed only after the stated evidence

• This is a proposed local project structure for organizing a source-linked learning course.
• The design includes lessons, study records, deadlines, workbacks, dependencies, revisions, accessibility checks, and uncertainty markers.
• Provider, credential, publication, external calendar, customer, and production effects remain held.

Still held

• The course is accredited, certified, complete, effective, or qualified.
• Sources have been independently verified beyond the supplied record.
• Any provider, database, credentialing service, calendar, messaging service, or publication channel is connected.
• Any learner has completed the course or achieved an outcome.
• Any record is indexed for customers or publicly published.
• Any deadline, duration estimate, accessibility accommodation, or instrument result is authoritative.

Sources and evidence

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

• source_record:project:learning-course
• NotebookCollectionKind.project
• NotebookTodoPayload.dueAt
• Notebook records preserve canonical IDs, provenance, revisions, lifecycle, tags, links, and attachments
• Notebook Agenda deadlines/workbacks
• PointGuard persistent cross-app context surface with specialist apps retaining execution and canonical-record ownership
• /app/notebook/projects/
• /app/notebook/field-guides/
• /app/notebook/to-dos/
• /app/notebook/agenda/
• /app/notebook/notes/
• /app/notebook/approvals/
• /app/notebook/search/