How to Explain Computer Requirements Before Enrollment: A Six-Column Checklist
We · November 2026
This is the fourth article in the "AI Learning Environment" series and the first written for institutions. The previous three stand on the student's side: Check This Table Before Enrollment sets thresholds across six tracks, Five Things That Stall Week One explains why an installed course still doesn't run, and From Script to Final Cut splits one comic-drama into six stops. This article asks a different question: when should that information have been said, by whom, and in what words.
This article evaluates no institution: no names, no comparisons, no rankings, and no business or legal advice. The configuration figures come from the system requirements carried on app detail pages and the hardware requirements on our own workflow pages, compiled in November 2026, and are a reference for judgment rather than a promise.
1. Why this has to be said before payment
Public complaint platforms carry consumer reports in which one pattern repeats in AI-course environment disputes: before enrolling the person was told only that "any computer will do", and after paying discovered the course needs a discrete graphics card, extra hardware, or a paid cloud route — by which point the refund window had closed. These disputes are hard to settle not because the two sides remember things differently, but because the one item that should have been written down is precisely the one that wasn't.
The first three articles of this series broke "it won't run" into three break points: the student's hardware falls short, a component the course depends on has limited support on one platform, and the course's pinned versions don't match the student's environment. Of those three, the first can be settled during the enquiry call and the second can be caught in a single pre-course self-check — only the question of whether to say it early involves no technology at all. It is purely whether the process schedules it.
That's why this one is written for institutions. Hardware requirements are the one disclosure in a course that can be settled in a sentence and confirmed by one check. Teaching results are hard to promise, contract terms are hard to change, service boundaries depend on communication. But "can this machine keep up with the course pace" can be verified on the spot. Whoever moves that earlier keeps one of the most expensive classes of dispute out of the picture before payment.
One point needs stating: not being able to say it is usually not unwillingness — nobody handed over a checklist. An admissions officer typically holds a syllabus and a sales script; tool names, versions and whether training is required sit with the curriculum team, and the two rarely align before a course opens. So the first use of the checklist below isn't as phrasing. It is to force one concrete handover between curriculum and admissions.
2. The six-column disclosure checklist
This table is the only thing to carry out of the article. All six columns are checkable without any technical skill, and each one lists the most common wrong wording — because most disputes don't come from an omission, they come from something written that says nothing.
| Column | What to state | The commonest wrong wording | How a student verifies it |
|---|---|---|---|
| ① System and chip | Windows 10/11; on macOS, write Apple silicon and Intel chips separately | "Runs on Windows / Mac" | On Windows: About This PC. On Mac: the Apple menu → About This Mac, and whether it shows a chip name or Intel |
| ② Is the student's machine Windows or Mac | Its own column, stating how far each class of machine gets | Treating a Mac as "a Windows machine with less spec" | The macOS line on a detail page is written one of two ways: M-series chips only, or supports Intel and M-series chips |
| ③ VRAM / memory / disk | Report all three together; size disk as "the app plus its first weights" | "A discrete graphics card is required", or VRAM alone | Task Manager → Performance → GPU for dedicated VRAM; on Mac, "Memory"; free space on the install drive |
| ④ Tool list and versions | Name each app; state the version if the course pins one | "You'll use AI drawing software" | Take the list and look up each detail page; the entry you can't find is the one to press about |
| ⑤ Inference or training | Whether assignments require training a model on the student's own material | Dismissing it as "we cover model fine-tuning" | Ask one sentence: "does the homework require training a model on my own voice or images?" |
| ⑥ Downgrade path and refund boundary | Which step you drop to when it won't run; what state refunds and what state doesn't | "Cloud learning is supported" | Ask for the downgrade method to appear in the course description; ask for the refund policy in writing |
Three notes.
First, the column order is the order to ask in. ①②③ are "what is your machine", ④⑤ are "what does the course ask of it", ⑥ is "what happens when they don't match". Drop any group and the answer stops holding.
Second, ⑤ is the column most often skipped and the costliest one. For inference alone, many apps produce a result on CPU. Once the assignment says "produce a model out of your own material", VRAM, runtime and disk all get recalculated. Most cases of a successful install and a missing assignment come from those two steps being written as one. In app detail pages the training tier usually gets its own sentence — the Kohya-ss page, for example, states Windows 10/11 64-bit, NVIDIA with 8GB+ VRAM, 32GB RAM and 20GB of disk advised. When a sentence like that appears on a training app, it signals that "can I open this software" and "can I do the assignment" are two questions.
Third, ⑥ is the column an institution least wants to write and the only one that proves the first five aren't a script. An institution willing to write "if it won't run we go to the lite edition, and if that fails the lab" usually has honest numbers earlier in the list. One that will only say "we provide a cloud classroom" often hasn't assembled a tool list at all.
3. What counts as actually writing a column down
A checklist isn't enough; wording decides it. Three rules, each with a self-test by counterexample.
Rule one: give numbers, not adjectives
Sentences like "a reasonably good computer" or "a high-end card is suggested" are blank spaces in a dispute. Write the checkable form instead: 8GB of VRAM, 16GB of memory, 100GB of disk reserved. Across the applications we've compiled, 8GB of VRAM is the densest dividing line — above it "runs at course pace", below it "pick a downgrade tier". On the image side, the mainstream large tiers are stated as starting at 12GB on our own workflow pages; on the video side the quantized tiers start at 16GB and are picked by GPU architecture. Those numbers aren't there to look professional; they're there so a student can find the matching box on their own machine.
Rule two: give tiers, not a single point
"One sentence: you need 8GB of VRAM" is wrong for two people at once: someone on 6GB assumes they're excluded, someone on 12GB assumes they're cleared for everything. The correct form is three tiers: the minimum gets you this far, the recommended finishes the course at pace, and below the minimum you take this downgrade route. Article one of this series already published that cross-table by track; citing it is easier than restating it, and it prevents two sets of numbers circulating.
Rule three: give paths, not promises
The four words "guaranteed to run" cannot be honored on environment matters — tools update monthly and the same app errors differently on different machines. What can be promised is a path: when it won't install, check these three things first; when you can't find the answer, ask this person; when you ask for help, bring this information. The second article ends with the six items a help request must carry (OS version, card or chip plus VRAM/unified memory, app name and version, which workflow or model file, the complete error sentence, and whether the minimal example runs). Print that on the page handed out before the course opens; it works better than replying "send us a screenshot" ten times in the group.
The disk column deserves its own reminder because it's the most commonly omitted. An app body is often tens of megabytes, but the first weights are counted in gigabytes, and by the third model in a track you're at tens of gigabytes. Walk a comic-drama pipeline through on the smallest combination and disk has to be reserved near the 100GB level. "It runs but I can't fit it" is a real category of failure, and at the enquiry stage one sentence prevents it: "please reserve 100GB or more and install into an English-only path".
4. Why "Windows or Mac" gets its own column
This is the only item in the checklist cut by platform rather than by spec, and the reason is that the two classes of machine hit different walls; answering both with one sentence guarantees misleading one of them.
On Windows the reported problem is capacity: not enough VRAM produces an out-of-memory error, and lowering resolution or switching quantization tier usually pushes it down. On Mac the reported problem is usually not capacity: unified memory on Apple silicon is often roomier than the VRAM on a card at the same price, and the blocker is that in the generative ecosystem a large share of custom nodes and operators are implemented against CUDA. When operators are missing on MPS, the error reads like a broken environment when in fact that path simply was never built on this machine. So for the same "AI short-drama voice" module, an NVIDIA student and a Mac student may end up with different installations — that isn't one side being better equipped, it's two technical lines.
The test is really one sentence and needs nobody's input: detail pages write macOS support two ways only. Written "M-series chips only" puts older Intel Macs outside the range; only "supports Intel and M-series chips" covers both; and an app that doesn't mention macOS at all is treated as Windows-only. An admissions officer who memorizes that line clears most of the enquiry traffic.
What actually needs a curriculum answer is a different sentence: does any workflow the course uses contain nodes that support CUDA only. Institutions usually can't answer that themselves, and it is precisely what decides whether Mac students can hand in work independently. If curriculum has no answer, then this course has no delivery plan for Mac students — and saying so before payment is far cheaper than saying it in week two.
One adjacent cell: if the course involves students delivering work publicly, whether the models and tools may be used commercially is a question for the institution's legal side, not something the environment layer resolves. We don't make legal conclusions on an institution's behalf inside a course; the per-item statements live in Model Licenses Explained and Why Training Institutions Choose Open Source. This article only notes that the question should be asked, and stops there.
5. Refunds and invoices: keeping the dispute out of the sale
Environment disputes all end at the refund, so column six has to be specific. The checkable form splits state into three:
| State | What must be explained | Where it usually goes vague |
|---|---|---|
| Not installed | Payment made, install not started — is a full refund available, and how long until it arrives | Writing "refunds supported" with no deadline and no settlement period |
| Installed, unused | It's on the machine but the course requirement never ran — does that count as the service being delivered | Treating "it installed" as "service complete" |
| Used | After which step refunds stop, and why | Using "class hours consumed", which has nothing to do with an installation service |
Three accompanying sentences must be written with them: what exactly is being charged (installation service separated from tuition), whether an invoice is issued and under what line item, and whether any instalment plan is involved. One bottom line is worth stating plainly: no steering into instalments, no "learn now, pay later" loan arrangements, and no "guaranteed to master it", "guaranteed employment" or "full refund if you don't pass" — none of those three promises can be honored by us or by any institution on an environment question.
Our own policy is included here as a sample that can be compared against, because it too needs checking. After the installation fee is paid, a refund may be requested without reason within 3 days; past 3 days the order enters the maintenance period. Service orders are bound to an account, so reinstalling the system or switching computers and logging back in costs nothing extra. Where a delisting results from an upstream authorization change outside our control, the service fee is refunded within three months with no further liability. The installation service does not include tutorials or teaching. The full wording is in the Installation Service Purchase Notice and the After-Sales Notice for Installation Services.
This isn't here to sell ourselves. It's here to make one point: sentences like this can be written this specifically. If they can, there is no reason for a pre-sale message to leave only "contact me anytime if there's a problem".
6. Four moments, and what each one says
A checklist only stops being a marketing page once it's wired into a process. Four moments, what to say at each, and what record to leave behind:
| Moment | What to say | What record to keep |
|---|---|---|
| First enquiry call | Ask which class the student's machine belongs to before introducing the course; deliver columns ①②③ | One line: "Windows or Mac, and how much VRAM or memory" |
| Before payment | Hand over the tool list and versions (④⑤) and the three refund states (⑥) | A written version the student confirmed, something they can screenshot and revisit |
| The week before the course | Have every student run one minimal example: install one app, produce one image or one voice clip | Pass or fail, with failures collected and sorted by error |
| Week one | Answer questions in the troubleshooting order; collect help requests by the six items | Categorized high-frequency errors, fed back to curriculum to fix the course |
Among these four, running one minimal example the week before the course is the highest-return step. It needs no lab and no new tool — only that each student, after paying and before the first class, spends ten minutes confirming this machine can produce a result. Someone who fails at this moment is found while the institution still has a downgrade to offer. Found in week three, only the refund path is left.
7. Standard answers to five recurring questions
This section is a model for compliant wording and can be used directly. One principle: give something checkable in the answer, not reassurance.
| The student asks | Don't answer like this | Answer like this |
|---|---|---|
| "I have an i5, can I take this?" | "Yes, no problem" | "An i5 doesn't answer the question. Could you open Task Manager → Performance → GPU and tell me whether there's a discrete card and how much dedicated VRAM? The image module of this course is tiered at 8GB; below 8GB you'd go to the lite edition or the lab." |
| "Can I use a Mac?" | "Macs work too" | "It depends which Mac. Apple silicon installs fine, and drawing, voice and transcription have fairly wide support. If your course uses nodes that support CUDA only, Mac will error, and I'd need to ask our curriculum team before answering that. For an older Intel Mac we'd only recommend the lite voice tiers." |
| "If my spec isn't enough, do I need a new computer?" | "We'd suggest buying a high-end one" | "Don't buy yet. Which tier your machine is in, and how far that tier gets through the course — we'll decide once we've gone through the checklist together. Many steps have a lite edition or a lower resolution to fall back on; hardware only has to change if the course explicitly requires training on your own machine." |
| "With a cloud classroom, does spec stop mattering?" | "A cloud classroom does everything" | "The cloud classroom is a fallback, not a replacement. Whatever runs locally is cheaper to keep local and easier to hand in from. For the cloud part, ask which GPU tier you get, how it's billed, and whether it stalls. We'd suggest writing all three into the contract." |
| "If it won't install, can I get a refund?" | "Of course you can" | "Refunds follow the state: not installed, installed but unused, and used are handled differently. I'll send you the written policy and you can pay after confirming it." |
The shared shape of all five answers is: first a checkable action, then a number, then a path. Nowhere in them does a competitor get mentioned or a result get promised.
8. Our view
First, pre-sale disclosure isn't a goodwill question; it's a process question. It needs no extra technical capability from the institution — only that curriculum writes the tool list, the versions, and whether training is required into a document and hands it to admissions. Most institutions don't, not because the teachers don't understand, but because those two groups never have a formal handover. Use this checklist as a handover template and it's worth far more than as a script.
Second, stating the threshold clearly doesn't reduce enrollment; it reduces disputes. We can't prove that with data, and this series won't carry any claim of the form "refund rates fell by X%" — we don't have that measurement. Mechanically, though: a student who learns their machine falls short and receives a downgrade plan, and a student persuaded by "any computer will do", are in completely different positions at the end of week one. The first is a little slower; the second comes back to find you.
Third, transparency is inspectable. The advantage of a six-column checklist isn't that it's comprehensive; it's that it makes vagueness visible. The moment somebody leaves the "④ tool list" cell blank, or fills "⑥ refund boundary" with "cloud learning supported", the reader knows immediately that this course isn't ready to deliver. For students that visibility is a screening tool; for institutions it's a self-check; for us it's the same thing — and it's why our own purchase and after-sales wording appears verbatim in section five: a promise that can be compared against is a promise.
The next article moves to the curriculum side: the software interface shown in a recorded course goes out of date every quarter, so how does a course environment get version-pinned, when should a version be locked, and how do you maintain an older cohort. That is article five of this series.
Disclaimer: The configuration statements in this article come from the system requirements carried on app detail pages, the hardware-requirement copy on our workflow pages, and upstream projects' public documentation, compiled by us in November 2026; software and model versions update monthly and requirements may change. The material on pre-sale disclosure, refunds and invoices is a method and a wording example; it is not legal or business advice and refers to no specific training institution. Individual cases from public complaint platforms illustrate categories of problem only, are always phrased as "a consumer reported", and are not findings of fact. This article evaluates and recommends no institution or course and makes no earnings claims.