Course 001 · applicant information handling
Manual beta routePrivacy boundaryNo CRM automation yet

Course 001 applicant data notice.

This page explains, in practical terms, how Course 001 founding learner interest details are used during manual review, applicant communication, access issue and beta improvement work.

v1.66.0 application record

Information used for the manual fit review.

The Course 001 application may collect name, email, business or project name, public website or social link, role, current presence stage, intended learning outcome, weekly implementation capacity, route expectation, evidence readiness, practical access adjustments and the applicant’s own description of the current need.

Data minimisation: applicants should not submit medical records, identity documents, bank information, passwords or unnecessary sensitive personal information through the public form. Any practical accessibility adjustment should be described only to the extent required to support participation.

A non-identifying application reference is generated in the browser and submitted with the form. The application remains subject to manual review and does not create enrolment, access, payment or recognition rights.

What the Academy uses applicant details for.

Course 001 interest details are used to receive and review founding learner interest, respond to applicants, assess course fit, issue manual access where approved, manage a small beta cohort, gather course-improvement evidence and keep proportionate operational records.

The current route is manual. Submitting interest does not create payment, checkout, automatic enrolment, automatic course access, automatic certification, accreditation, public testimonial permission or any business-result guarantee.

Minimum useful data

What the form may collect.

The Course 001 interest form asks for enough information to assess fit and respond. It is not designed to collect unnecessary sensitive, medical, legal, financial or crisis information.

Check readiness
IdentityName and emailUsed to respond and identify the submission.
ProjectBusiness or project contextUsed to assess whether the course is a suitable learning route.
ReadinessStage, goal and capacityUsed to support manual screening and realistic expectations.
ConsentAcknowledgement fieldsUsed to record that the applicant understands the manual beta boundary.

Publication and testimonial boundary.

Application details, learner feedback, screenshots, names, business names and testimonials should not be published from a form submission alone. Public use requires a separate written permission or clearly recorded consent boundary.

Retention and deletion.

Applicant records should be kept only for as long as they remain reasonably needed for communication, access management, cohort administration, beta evidence, legal/accounting protection or operational record-keeping. Records no longer needed should be deleted, anonymised or separated from identifiable details.

Questions, correction or removal.

Applicants may contact the Academy to ask about details they submitted, request correction of obvious errors, opt out of further Academy communication, or request deletion where continued retention is not reasonably required.

Learner agreement status.

Review the pre-access agreement, support scope, cancellation/refund acknowledgement and digital-content consent boundary before any paid digital access is issued.

Paid learner account and order data.

The D’Key Commerce account route adds a separate set of operational records to the earlier interest-form data: learner name and email, salted password hash, server-session record, Course 001 order reference, price and payment rail, checkout acknowledgement timestamps, bank reconciliation or regulated-provider payment reference, entitlement state, receipt record and any recovery/refund administration required for the account.

Payment-data boundary: Academy forms and server functions are not designed to receive raw card numbers, CVC values, PINs or magnetic-stripe data. Future card credentials must remain inside the regulated provider’s payment component.

The public paid route remains fail-closed until the legal merchant identity, final Course 001 price, receiving account and explicit public-checkout switch are configured. Deploying the commerce code alone does not activate paid enrolment.