AI & Digital Quality School · Learning track
Reduce ordinary business cyber risk through disciplined everyday controls.
Start Lesson 1No signup, cloud storage, cross-device sync or verified completion. Saving is optional. This browser profile is shared with anyone who can use it; private mode, browser cleanup or storage limits may remove work. Use only fictional or non-sensitive material. Export a copy before relying on this device.
Not saved. Worksheets, answers and practice notes currently last only in this tab.
Practice markers are self-reported, never credentials.
A different tab changed this track. Nothing was overwritten. Export your current draft first if needed, then load the saved version before editing and saving again.
01 Learning plan
Public foundation 2026.10.08-learning-paths-1 · published 2026-10-08. Independent subject-matter review is pending; paid delivery and credential issuance remain closed. This track is organized around inspectable work, not attendance alone.
Workload
No validated completion time is published. Read the six modules, then complete the six case assignments and self-review across as many sessions as needed. This release has not yet been timed with learners; no facilitated capstone is included.
Prerequisites
Outputs
Working vocabulary
02 Public foundation curriculum
Each module states what to understand, what to practice, what evidence to retain, and the criteria for moving forward. The case lab turns those standards into six realistic assignments.
Module 1
Objective: Identify the business assets and plausible harms that matter most, assign ownership, and prioritize defensive actions without pretending to perform a full professional risk assessment.
Open Lesson 1: examples, worksheet & feedback →Cybersecurity protects the work the organization must continue and the people who could be harmed. Inventory critical accounts, devices, applications, data, vendors, payment paths, domains, backups, and operating processes. For each asset, name an accountable business owner, technical custodian, authorized users, dependencies, and consequence of loss of confidentiality, integrity, or availability. Begin with crown-jewel and single-point-of-failure assets rather than attempting a perfect inventory. Include services managed by outside providers because outsourcing operation does not remove business responsibility.
Describe plausible threat events in plain language: account takeover, payment-change fraud, ransomware, lost device, malicious or mistaken insider action, vendor compromise, exposed cloud share, domain hijack, service outage, or destroyed backup. Then record current protections and the next proportionate improvement. Governance matters: leaders set priorities and risk tolerance; system owners approve access; users follow controls and report problems; IT or security specialists implement and investigate technical safeguards. This course supports baseline decisions but is not a penetration test, compliance certification, legal opinion, or substitute for qualified incident, privacy, or security professionals.
Practice
Map fifteen assets for a fictional 25-person company, select the five highest-consequence assets, and pair each with one plausible event, current control, owner, and next action.
Evidence to keep
Submit the prioritized inventory, responsibility map, rationale, known gaps, and specialist questions that require deeper assessment.
Ready to move on when
Module provenance
External authorities, common professional practice, and Academy-selected controls are identified separately. A source supports only the stated scope; it does not convert this lesson into legal, licensed, accredited, or regulatory advice.
Module 2
Objective: Apply organization-approved authentication, recovery, access, and offboarding controls to high-value accounts and eliminate insecure credential handling.
Open Lesson 2: examples, worksheet & feedback →Start with the accounts that can change money, identity, email, domains, cloud configuration, customer data, payroll, source code, or other access. Use unique passwords generated and stored in an organization-approved password manager, and enable the strongest practical multi-factor method approved for the service. Phishing-resistant methods such as hardware-backed authenticators or passkeys can provide stronger protection than codes that users may be tricked into relaying. Never share passwords or one-time codes by email, chat, phone, or document. Service and shared accounts require named ownership, scoped permissions, monitored use, and a controlled alternative to informal shared credentials.
Recovery is part of authentication. Inventory recovery email, phone, backup codes, administrators, vendor support routes, and proof required for high-value services. Protect recovery channels at least as carefully as the account they restore. Test the documented process without locking out production work, and store emergency material securely with limited, auditable access. Joiner, role-change, and leaver workflows should grant, review, and revoke access promptly. Review privileged access and inactive accounts on a schedule. Exact authentication requirements depend on risk, service capabilities, and applicable obligations; security and identity specialists should approve high-assurance or regulated implementations.
Practice
Create an account-control matrix for twelve fictional services, then design a safe onboarding, role-change, offboarding, and emergency-recovery checklist.
Evidence to keep
Submit account owners, roles, MFA methods, recovery channels, review frequency, offboarding actions, and unresolved high-risk gaps without including real credentials.
Ready to move on when
Module provenance
External authorities, common professional practice, and Academy-selected controls are identified separately. A source supports only the stated scope; it does not convert this lesson into legal, licensed, accredited, or regulatory advice.
Module 3
Objective: Recognize common manipulation signals, verify consequential requests through known channels, and report suspicious communication without interacting further.
Open Lesson 3: examples, worksheet & feedback →Phishing succeeds by exploiting urgency, authority, fear, curiosity, routine, or a believable business context. Warning signs include unexpected credential prompts, changed payment instructions, unusual secrecy, bypassed approvals, mismatched domains, unfamiliar sharing requests, attachment pressure, and a request to relay a code. A message can look polished, use familiar names, and come from a compromised real account. Do not rely on spelling errors as the main test. The important question is whether the requested action is expected, authorized, and independently verifiable.
Pause before acting on a consequential request. Use a known phone number, approved directory, existing ticket, or separate verified channel rather than contact details inside the message. Inspect links using approved tools without opening suspicious destinations, and do not forward dangerous attachments broadly. Report through the organization's designated mechanism, preserving the original message and relevant context. If credentials or codes were entered, money moved, malware opened, or sensitive data disclosed, contact the incident path immediately and follow instructions rather than attempting unsupervised cleanup. Training simulations should be authorized, respectful, privacy-conscious, and designed for learning rather than embarrassment or punishment.
Practice
Review twelve synthetic messages and classify the requested action, risk, verification channel, report decision, and immediate response if interaction already occurred.
Evidence to keep
Submit the classification record, payment-change verification procedure, reporting card, and a short explanation of why visual polish does not prove authenticity.
Ready to move on when
Module provenance
External authorities, common professional practice, and Academy-selected controls are identified separately. A source supports only the stated scope; it does not convert this lesson into legal, licensed, accredited, or regulatory advice.
Module 4
Objective: Maintain a visible baseline for supported devices and software using secure configuration, timely updates, protection, encryption, and controlled exceptions.
Open Lesson 4: examples, worksheet & feedback →An organization cannot protect devices it does not know about. Record owner, user, device identifier, operating system, support status, encryption, screen lock, endpoint protection, backup coverage, administrator rights, and last review. Separate ordinary user activity from administrative access. Use organization-managed devices for sensitive work where required and define whether personal devices are permitted, what data they may access, and how lost or departed devices are handled. Physical control matters: unattended screens, shared family devices, and unencrypted removable media can bypass otherwise strong online controls.
Use supported software from approved sources and apply security updates within risk-based targets. Critical exploited vulnerabilities may require faster action, but updates should still follow tested change and rollback procedures appropriate to the system. Remove unused applications, browser extensions, local administrators, and end-of-life devices. An exception should name the business reason, risk owner, compensating controls, expiration, and replacement plan. Do not run scanners, exploit tools, or configuration changes against systems without authorization. Complex infrastructure, vulnerability management, mobile-device management, and regulated environments require qualified technical specialists and vendor-specific guidance.
Practice
Assess a fictional device and software inventory containing unsupported systems, excessive administrator access, unapproved extensions, missing encryption, and delayed updates.
Evidence to keep
Submit the corrected baseline, prioritized remediation plan, exception record, owners, deadlines, and a safe update-and-rollback checklist.
Ready to move on when
Module provenance
External authorities, common professional practice, and Academy-selected controls are identified separately. A source supports only the stated scope; it does not convert this lesson into legal, licensed, accredited, or regulatory advice.
Module 5
Objective: Reduce data exposure by defining approved storage, sharing, retention, vendor, backup, and restoration practices tied to business impact.
Open Lesson 5: examples, worksheet & feedback →Classify information by sensitivity and consequence, then define where each class may be created, stored, shared, discussed, exported, retained, and destroyed. Minimize collection and access; a smaller, controlled data set is easier to protect. Use approved encrypted services and permission groups rather than public links, personal email, consumer file transfer, or unmanaged copies. Periodically review external shares and departed users. When law, contract, records policy, or regulated data is involved, follow qualified privacy, legal, records, and security guidance rather than applying a generic label.
Vendors should be evaluated according to the service and data risk. Record owner, purpose, data, access, authentication, incident notice, backup responsibility, recovery expectations, subcontractors, retention, deletion, and exit method. Backups must be separated enough to survive the same failure, protected from unauthorized deletion, monitored, and tested through restoration. A successful backup job is not proof that the organization can recover the right system within an acceptable time. Define recovery-time and recovery-point needs with business owners, then test a representative restoration and document what was missing, slow, or dependent on a vendor.
Practice
Map a fictional customer-file lifecycle across collection, cloud storage, vendor processing, staff sharing, archive, deletion, backup, and restoration.
Evidence to keep
Submit the data-flow, approved-location rules, vendor questions, access review, retention and deletion rule, restoration test, and corrective actions.
Ready to move on when
Module provenance
External authorities, common professional practice, and Academy-selected controls are identified separately. A source supports only the stated scope; it does not convert this lesson into legal, licensed, accredited, or regulatory advice.
Module 6
Objective: Recognize possible incidents, preserve safety and evidence, use the approved reporting path, and support coordinated response and recovery without exceeding role authority.
Open Lesson 6: examples, worksheet & feedback →Possible incident signals include unexpected MFA prompts, disabled security tools, unusual forwarding rules, locked or encrypted files, missing devices, unauthorized transactions, vendor notices, exposed shares, new administrators, suspicious login alerts, or reports that data reached the wrong person. Employees do not need to prove an incident before reporting. The first-actions card should name internal and alternate contacts, information to capture, prohibited actions, and emergency routes. Record what was observed, when, on which asset, by whom, and any actions already taken. Do not delete messages, wipe systems, confront a suspected actor, or investigate beyond authorization.
Response coordinates preparation, detection, analysis, containment, eradication, recovery, communication, legal and regulatory duties, and improvement under qualified leadership. Immediate actions depend on the incident; disconnecting or powering off a device can either limit harm or destroy evidence, so follow the approved responder's direction. Keep customer, employee, media, regulator, insurer, law-enforcement, and vendor communications with authorized owners. Recovery verifies restored systems, credentials, integrations, data integrity, monitoring, and business service before declaring success. Conduct a blameless after-action review, assign corrective actions, and test the changed control. Serious incidents require experienced security, legal, privacy, insurance, and possibly law-enforcement support.
Practice
Run a tabletop involving a suspicious mailbox rule, fraudulent payment request, unavailable backup administrator, and a public social-media allegation.
Evidence to keep
Submit the event timeline, contact tree, first-actions card, decision log, communication ownership, recovery checks, and after-action plan.
Ready to move on when
Module provenance
External authorities, common professional practice, and Academy-selected controls are identified separately. A source supports only the stated scope; it does not convert this lesson into legal, licensed, accredited, or regulatory advice.
Free operational lesson
Pause when a message changes payment details, requests credentials, creates urgency, or bypasses normal approval. Verify through a known channel—not the contact details inside the suspicious message.
Identify critical assets, data, accounts, vendors, dependencies, owners, and consequences before selecting controls.
Minimize data and access, remove unsupported technology, and prioritize high-impact baseline protections.
Use approved authentication, devices, software, storage, sharing, vendor, and backup practices.
Verify unusual requests and route suspected incidents through known channels without destructive or unauthorized action.
Restore under coordinated leadership, verify service and data, learn from evidence, and retest corrective controls.
Worked example
An accounts coordinator receives a realistic email from a known vendor contact asking that an urgent invoice be paid to a new bank account before the end of the day.
The sender name and prior email thread look correct, so update the bank details and pay quickly to avoid a late fee.
Do not use the phone number or link in the message. Pause the change, open the existing vendor record, call the previously verified contact, and require the organization's second approval for bank-detail changes. Report the suspicious message through the security path and preserve it. If any payment or credential action already occurred, activate the incident and financial-fraud response immediately.
Why it matters: The improved action assumes that a real mailbox or thread can be compromised, uses an independent channel, preserves dual control, and escalates possible harm promptly.
03 Control the work
Common failure modes
Domains, cloud administrators, email, vendors, payment paths, backups, and business processes can be more consequential than an individual device.
Methods differ in phishing resistance, recovery design, and implementation; account consequence should shape the approved method.
A job can report success while the data is incomplete, inaccessible, unprotected, or too slow to restore for business needs.
Uncoordinated deletion, scanning, confrontation, or system changes can increase harm and destroy evidence needed by authorized responders.
Operating measures
The percentage of inventoried high-value human and administrative accounts protected by the organization-approved MFA method.
Use it to decide: Prioritize uncovered or weak-method accounts by consequence and document service limitations and compensating controls.
The percentage of in-scope critical security updates applied or formally excepted within the approved risk-based time target.
Use it to decide: Investigate ownership, asset visibility, vendor dependence, testing, and exception quality when attainment falls.
The percentage of scheduled representative restoration tests that meet defined data integrity, recovery-point, and recovery-time expectations.
Use it to decide: Treat failed or incomplete restoration as a recovery-control defect with an owner and retest date.
Elapsed time between a person's first observable warning sign and the organization's receipt of a usable report.
Use it to decide: Simplify reporting, improve awareness, and clarify no-blame expectations when avoidable delay appears in exercises or incidents.
04 · Applied case lab · 2026.08.31-practice-3
The packet contains contradiction and incomplete evidence on purpose. Each assignment now identifies the exact fictional inputs available to the learner. Complete a bounded starter, mark missing records instead of inventing them, and compare your reasoning with the debrief—not with a pretend single perfect answer.
This fictional, sanitized defensive-security case contains no real credentials, account numbers, personal data, or exploitable instructions. It is not legal, forensic, insurance, or cybersecurity assurance.
CB01 · citable versioned case brief
SilverPine Fabrication is a fictional 38-person manufacturer. At 9:12 a.m., accounts payable received an email inside an existing supplier thread requesting that the next $84,600 payment move to a new bank. The message used the supplier controller's display name and included an attached letter, but the phone number on the letter differs from the approved supplier record. At 9:26, an employee opened the attachment and entered a cloud password on a page that later disappeared. At 9:31, a push-notification approval arrived; the employee denied it and called the office manager. The manager told the employee to change the password from the same laptop but did not contact the incident lead. Email logs available to the internal administrator show a new forwarding rule created at 9:29 and a login from an unfamiliar region. The laptop reports that endpoint protection last checked in 11 days ago. The supplier master record can be changed by three accounts; one belongs to a former contractor and has no recorded multi-factor authentication. Backups run nightly to a connected network share. The dashboard is green, but the last documented restoration test occurred 14 months ago and recovered only one folder. The company's incident sheet lists names but no after-hours method, severity criteria, evidence-preservation steps, payment-hold authority, or customer and regulatory decision process. No payment has been released. Learners must map assets and responsibility, protect authentication and recovery, verify communication independently, manage device and software actions, assess data, vendor, and backup controls, and construct an authorized incident response. They must not investigate outside authorization, contact an attacker, destroy evidence, or declare breach scope and legal notification obligations without qualified review.
Judgment required: Contain immediate risks and preserve evidence while qualified responders determine scope.
Do not assume: Do not assign blame or declare the incident source from display name, thread position, or one login alone.
Judgment required: Define a safe representative restore test and interim resilience measures based on business needs.
Do not assume: Do not call backups reliable solely because scheduled jobs report success.
Bounded case starter
Identify critical processes, assets, owners, dependencies, consequences, and immediate authority gaps.
Deliverable: A prioritized asset-process map and responsibility matrix.
Completion boundary: Complete a bounded starter and gap analysis using only CB01, F01, F02, F03, F04, F05, F06, F07, F08, F09, F10, F11, F12, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.
Workbook plan: 2 authored artifacts with 15 stable practice rows. The download includes a prerequisite check, six-to-eight task-specific operating steps, field-by-field guidance, completed supported and known-gap examples, supporting-artifact examples where authored, stop/go/escalate rules, and an exact completion test.
Provided inputs
Evidence criteria
Debrief lens: The incident is a business-process problem involving identity, payment, supplier, device, and recovery controls. Prioritization should reflect consequence and decision authority, not product inventory alone.
Bounded case starter
Draft authorized account-protection and recovery steps that require a known-clean channel and administrator; do not execute containment from the training packet.
Deliverable: An identity-containment checklist and access-review record template with every action, owner, authorization, time, and result field pending.
Completion boundary: Complete a bounded starter and gap analysis using only CB01, F03, F04, F05, F06, F07, F08, F09, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.
Workbook plan: 2 authored artifacts with 15 stable practice rows. The download includes a prerequisite check, six-to-eight task-specific operating steps, field-by-field guidance, completed supported and known-gap examples, supporting-artifact examples where authored, stop/go/escalate rules, and an exact completion test.
Provided inputs
Evidence criteria
Debrief lens: Changing a password from the same device may not end active sessions or address recovery paths. Qualified identity containment should use a trusted channel and preserve logs.
Bounded case starter
Create an independent communication and payment-change control that does not trust the suspect thread.
Deliverable: A payment-hold decision record and out-of-band verification plan that marks the approved supplier contact identity and verification result not supplied.
Completion boundary: Complete a bounded starter and gap analysis using only CB01, F01, F02, F12, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.
Workbook plan: 2 authored artifacts with 3 stable practice rows. The download includes a prerequisite check, six-to-eight task-specific operating steps, field-by-field guidance, completed supported and known-gap examples, supporting-artifact examples where authored, stop/go/escalate rules, and an exact completion test.
Provided inputs
Evidence criteria
Debrief lens: The safest verification does not use contact details in the suspect message. Payment change and payment release should require independent, documented approvals.
Bounded case starter
Replace improvised password changes with an authorized device and software response path.
Deliverable: A device triage decision tree and approved-software baseline exception.
Completion boundary: Complete a bounded starter and gap analysis using only CB01, F03, F06, F07, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.
Workbook plan: 2 authored artifacts with 11 stable practice rows. The download includes a prerequisite check, six-to-eight task-specific operating steps, field-by-field guidance, completed supported and known-gap examples, supporting-artifact examples where authored, stop/go/escalate rules, and an exact completion test.
Provided inputs
Evidence criteria
Debrief lens: Uncoordinated deletion or reimaging can destroy evidence. The learner should identify safe first actions and defer forensic acquisition and eradication to authorized specialists.
Bounded case starter
Map the data, vendor, and backup questions and design a representative restore test; do not access systems or perform restoration.
Deliverable: A data-flow and vendor-register starter plus a restore-test plan with test execution and recovery results pending.
Completion boundary: Complete a bounded starter and gap analysis using only CB01, F05, F10, F11, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.
Workbook plan: 2 authored artifacts with 8 stable practice rows. The download includes a prerequisite check, six-to-eight task-specific operating steps, field-by-field guidance, completed supported and known-gap examples, supporting-artifact examples where authored, stop/go/escalate rules, and an exact completion test.
Provided inputs
Evidence criteria
Debrief lens: Backup success means little without representative restoration against business requirements. Data and vendor review should also identify notification questions without answering them prematurely.
Bounded case starter
Construct an incident-timeline starter and tabletop design from the supplied events; do not exercise response, contact external parties, or claim containment or recovery.
Deliverable: An incident-record starter, tabletop-inject plan, decision-register template, and after-action template with simulation and outcome fields pending.
Completion boundary: Complete a bounded starter and gap analysis using only CB01, F01, F02, F03, F04, F05, F06, F07, F08, F09, F10, F11, F12, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.
Workbook plan: 4 authored artifacts with 18 stable practice rows. The download includes a prerequisite check, six-to-eight task-specific operating steps, field-by-field guidance, completed supported and known-gap examples, supporting-artifact examples where authored, stop/go/escalate rules, and an exact completion test.
Provided inputs
Evidence criteria
Debrief lens: An incident record should separate observations from hypotheses and preserve every material decision. After-action work addresses both technical and payment-process weaknesses.
Self-review standard
There is no universal containment sequence for every incident. Strong work protects people and operations, preserves evidence, uses authority, and escalates legal and forensic conclusions. The downloadable rubric is formative guidance only—not a grade, verified completion, credential assessment, or professional approval.
Route to: Authorized incident-response, identity, endpoint, email, and forensic professionals
Learner boundary: The learner reports and preserves facts but does not conduct unauthorized investigation or destructive response.
Route to: Qualified counsel, insurer, financial institution, executive incident lead, and applicable authorities
Learner boundary: Training cannot determine legal duties, coverage, attribution, or notification obligations.
05 Editable working tool
Use one row per critical asset or account. Name a business owner, state the primary credible harm, record the current verified control, and choose one achievable improvement with an owner and target date. Never enter passwords, keys, recovery codes, or protected data. Add as many rows as needed, export a CSV, or print only this tool. Entries are not transmitted. They last only in this tab unless you opt into device-only saving in the learning-work panel. No account or cross-device sync is provided.
| Asset or account | Owner | Primary risk | Current control | Next improvement |
|---|---|---|---|---|
Completed example
Data boundary: Work only in an approved system. Do not place passwords, payment-card data, government identifiers, health information, export-controlled material, client secrets, or unpublished invention details in this public worksheet.
Each two-question check works independently. Review any answered question immediately; you do not need to finish all twelve. Feedback is formative, not a verified grade or credential.
07 Sources and handoffs
Module provenance distinguishes external authorities, legal-status evidence, and Wealth Synergy internal operating standards. Requirements change; verify current source text and obtain qualified advice when a decision carries legal, financial, technical, employment, safety, or regulatory consequences.
nist-csf-2-publication · Official guidance
Primary NIST framework for governing, identifying, protecting, detecting, responding to, and recovering from cybersecurity risk.
Open reviewed external source ↗cisa-cross-sector-cpgs · Official guidance
CISA's prioritized voluntary baseline practices, designed to help organizations focus on high-impact risk reduction.
Open reviewed external source ↗nist-sp-800-61-r3 · Official guidance
Current NIST guidance for integrating incident response throughout cybersecurity risk management.
Open reviewed external source ↗ftc-protecting-personal-information · Official guidance
FTC business guidance on data inventory, minimization, protection, disposal, and incident planning.
Open reviewed external source ↗ws-cybersecurity-operating-standard · Academy internal operating standard
Academy-selected asset, access, verification, device, backup, incident, and restoration controls; it does not authorize security testing. This is an internal operating standard selected by Foundry Academy; it is not law, accreditation, licensure, or an external-standard requirement.
Version 1.0 · reviewed 2026-09-01 · owner: Foundry Academy curriculum ownerDiscuss coordinated operational support when the baseline reveals work requiring qualified IT, security, privacy, legal, insurance, or vendor specialists.
Explore the handoff →Request a defensive team cohort for communication verification, access review, backup restoration, and incident tabletop practice using synthetic cases.
Explore the handoff →Future facilitated pathway · not open
The public case lab is available now. A future facilitated cohort may add assignments, feedback, and human capstone review only after a named qualified facilitator and reviewer, schedule, rubric, privacy controls, support, price, refund terms, and delivery terms are published in writing. No enrollment or payment is accepted here.
Course material supports professional development. It does not replace legal, tax, accounting, cybersecurity, engineering, regulatory, employment, translation, or other qualified professional advice where that expertise is required.
The public knowledge check and portal review markers are learning aids only. They do not award a credential. Pilot curriculum and credential assessment are in quality review; Foundry Academy is not currently representing these pages as accredited instruction or an automatic path to a certificate.
Participation does not guarantee employment, client work, funding, licensure, certification by a public authority, or any business outcome.
Use the public foundation
All public materials and case files are available without enrollment. A fit conversation is non-binding and does not reserve a place in a future pilot.
Ask about this track