AI & Digital Quality School · Learning track
Turn vague software concerns into reproducible evidence and release decisions.
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: Translate user and business outcomes into testable acceptance criteria prioritized by consequence, likelihood, exposure, and detectability.
Open Lesson 1: examples, worksheet & feedback →Quality begins with a shared definition of acceptable behavior. Identify users, goals, environments, dependencies, data, and consequences before writing tests. A requirement such as 'the form is easy to use' is not directly testable; clarify the intended user, task, condition, and observable result. Acceptance criteria should cover the normal path, important alternatives, invalid input, permissions, failure messages, recovery, and relevant accessibility or security expectations. Each criterion needs an approved source. When the source is ambiguous or conflicting, QA should raise the decision rather than silently choose the expected behavior.
Prioritize testing using risk, not feature visibility alone. Consider impact on people, money, safety, privacy, security, compliance, reputation, and continuity; then assess likelihood, frequency, exposure, change size, complexity, and how easily failure would be detected. A rarely used administrative permission can deserve more attention than a popular color change. Record assumptions and residual gaps so decision-makers know what was not tested. QA provides evidence and risk analysis; product, engineering, security, legal, accessibility, or other authorized owners decide within their roles. Testers must not perform intrusive or destructive work without explicit scope and permission.
Practice
Rewrite ten vague requirements for a fictional customer portal as measurable acceptance criteria and rank them using an impact-likelihood-exposure model.
Evidence to keep
Submit the clarified criteria, source links, risk scores, assumptions, open decisions, and rationale for the top five test priorities.
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: Create a proportionate test plan with controlled scope, representative environments, safe data, ownership, entry and exit criteria, and known limitations.
Open Lesson 2: examples, worksheet & feedback →A test plan explains what evidence will support a release decision. Define scope, excluded areas, risks, test types, environments, devices, browsers, roles, data, dependencies, responsibilities, schedule, entry criteria, exit criteria, defect rules, evidence storage, and reporting cadence. Map the plan to acceptance criteria and recent changes. Include recovery and negative paths, not only successful completion. Estimate based on risk and available capacity, then state what reduced scope means. A plan that promises complete coverage is not credible; software has too many states and interactions for exhaustive testing in ordinary projects.
The environment record is part of every result. Capture build or commit, configuration, operating system, browser or client, device, locale, time zone, account role, feature flags, integrations, and relevant data state. Use synthetic or authorized data and keep production credentials out of test artifacts. Confirm that test actions cannot notify real customers, charge real accounts, corrupt records, or overload systems. Differences between test and production must be documented because they limit inference. Security, performance, resilience, and destructive testing require approved methods and specialists where appropriate. If the environment changes during a run, record the change and reassess affected evidence.
Practice
Develop a test plan for a fictional subscription checkout across desktop and mobile, including payment stubs, role-based access, email suppression, and rollback boundaries.
Evidence to keep
Submit the plan, environment matrix, data strategy, traceability map, entry and exit criteria, and residual-risk statement.
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: Write repeatable test cases tied to acceptance criteria and capture evidence sufficient for another authorized tester to evaluate the result.
Open Lesson 3: examples, worksheet & feedback →A structured test case records its identifier, objective, requirement, risk, preconditions, data, environment, steps, expected result, cleanup, and evidence. Keep steps precise enough to reproduce but focused on behavior rather than irrelevant clicks. The expected result must come from a test oracle, not from the current application's behavior. Include equivalence classes and meaningful boundaries: empty, minimum, maximum, just inside, just outside, invalid format, duplicate, expired, unauthorized, and interrupted states where applicable. Avoid using one enormous case for an entire customer journey because a failure becomes hard to diagnose and rerun.
Evidence should support the conclusion without collecting more data than necessary. Screenshots are useful when they show state, but text logs, network records, accessibility-tree output, database assertions, or system events may be stronger. Record timestamps and identifiers that connect evidence to the case and build. Redact secrets and personal data, and do not place credentials in videos or defect tickets. Mark pass, fail, blocked, not run, or inconclusive using defined meanings. A passed check means the observed result met the criterion in the recorded environment; it does not prove the feature works in every environment or is free of defects.
Practice
Write and execute eight cases for password-reset initiation using only synthetic accounts, covering normal, unknown account, expired link, repeated request, localization, and keyboard behavior.
Evidence to keep
Submit the cases, oracle references, environment, sanitized evidence, results, and limitations for each untested condition.
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: Run time-boxed exploratory sessions that pursue a clear risk mission, adapt from observations, and preserve useful coverage and evidence.
Open Lesson 4: examples, worksheet & feedback →Exploratory testing is not random clicking. Write a charter that names the target, risk, users, data, techniques, time box, and prohibited actions. Begin with a model of the feature and vary one dimension at a time: sequence, timing, role, state, device, locale, network, data size, interruption, concurrency, or dependency behavior. Follow surprising observations while recording what was tried. Heuristics can broaden thinking, but they do not replace requirements or specialist methods. Stop when the charter is exhausted, the time box ends, or risk requires escalation.
Edge cases matter when they represent real boundaries or harmful failure, not merely unusual values. Test state transitions such as draft-to-submit, active-to-expired, authenticated-to-session-timeout, online-to-offline, and retry-after-partial-success. Consider daylight-saving changes, Unicode, long names, right-to-left text, zoom, assistive technology, duplicate requests, and permissions where relevant. Do not conduct denial-of-service, credential attack, injection, or unauthorized security testing under a general exploratory charter. Preserve notes, data, screenshots, and coverage so another tester can understand the path. Convert stable discoveries into repeatable regression tests and record untested questions.
Practice
Run a 60-minute charter against a fictional appointment workflow focused on interrupted sessions, time zones, duplicate submission, keyboard navigation, and stale availability.
Evidence to keep
Submit the charter, session timeline, coverage map, findings, converted regression cases, and open questions with owners.
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: Report defects with reproducible evidence, user and business impact, appropriate severity, and a clear distinction between severity and repair priority.
Open Lesson 5: examples, worksheet & feedback →A useful defect report reduces uncertainty. Record a concise title, environment, build, preconditions, exact steps, expected result and source, actual result, frequency, evidence, affected users, impact, workaround, and related changes. Confirm reproducibility when safe, then state if the issue is intermittent or not reproduced. Avoid conclusions about root cause unless investigation supports them. Duplicate reports should be linked without discarding distinct environments or impacts. Protect sensitive data and use the organization's confidential vulnerability path for security findings rather than a broadly visible ticket.
Severity describes impact; priority reflects sequencing under current constraints. A severe defect may wait briefly for a specialist or safe fix, while a minor defect may be repaired immediately because it blocks a launch asset. Define levels with examples covering safety, security, privacy, financial loss, data integrity, legal or accessibility barriers, core workflow failure, degraded function, and cosmetic impact. Critical classifications require an escalation and containment rule. Product and engineering owners may set priority, but changes to severity should preserve the reasoning and evidence. After repair, verify the exact defect and nearby regression risk in the corrected build.
Practice
Rewrite four poor bug reports, assign severity using a provided matrix, and conduct a safe retest of a fictional corrected defect.
Evidence to keep
Submit complete reports, severity rationales, duplicate analysis, retest evidence, and the regression scope selected around each fix.
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: Assemble risk-based regression and accessibility evidence into a transparent release recommendation with defects, gaps, ownership, and rollback readiness.
Open Lesson 6: examples, worksheet & feedback →Regression selection should follow change impact, dependency paths, defect history, critical customer journeys, permissions, data integrity, and operational controls. Maintain a small smoke set for rapid confidence and deeper suites for affected risks. Remove or repair flaky tests rather than treating reruns as normal evidence. Accessibility belongs throughout design and testing; combine automated checks with keyboard, zoom, focus, name-role-value, error, contrast, reflow, screen-reader, caption, and content review appropriate to the product. Automated tools find only part of accessibility risk, and conformance claims require qualified evaluation beyond this course.
A release recommendation summarizes build, scope, environments, results, open defects, critical criteria, accessibility findings, security or performance evidence, untested areas, data or migration checks, monitoring, support readiness, rollback, and named risk owners. QA recommends based on evidence; authorized stakeholders accept or reject residual risk. A signoff should never say 'bug-free.' If a critical criterion failed or required evidence is missing, state that clearly and recommend no release unless an authorized exception process applies. Preserve the test package and decision version so incidents can be compared with what was known at release time.
Practice
Prepare a release recommendation for a fictional build with one open accessibility barrier, two medium defects, a payment-service change, and incomplete older-browser coverage.
Evidence to keep
Submit the regression rationale, accessibility record, defect summary, coverage gaps, release recommendation, approvals, monitoring, 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.
Free operational lesson
Record the environment, starting state, exact steps, expected result, actual result, frequency, evidence, and user impact. A useful report reduces the next person’s uncertainty.
Turn user and business needs into testable criteria with an authorized expected-result source.
Allocate depth according to consequence, likelihood, exposure, change, complexity, and detectability.
Test safely in a recorded environment with authorized data, structured cases, and focused exploration.
Report defects and limitations with reproducible facts, objective evidence, impact, and uncertainty.
Connect results, accessibility, gaps, residual risk, monitoring, and rollback to an authorized release decision.
Worked example
On mobile, a customer completes checkout and taps Submit twice because the first tap provides no visible feedback. Two orders are created.
Checkout is broken on mobile. Sometimes it duplicates orders. Please fix ASAP.
Build 3.8.14, iOS 18.2, Safari, synthetic account QA-204. With a valid cart, throttle the network to Slow 3G, tap Submit twice within two seconds. Expected: one order and disabled or status-announced submission control. Actual: orders T-9102 and T-9103 are created in 3 of 5 runs. Customer impact: duplicate charge risk. Evidence: sanitized screen recording, timestamps, and server event IDs. Severity: high under the approved matrix; disable repeated submission or contain before release.
Why it matters: The improved report identifies state, environment, exact action, expected behavior, frequency, evidence, impact, and containment without guessing at root cause.
03 Control the work
Common failure modes
Expected behavior must come from approved requirements or standards; otherwise a defect can be encoded as the expectation.
Normal success cannot reveal many permission, boundary, interruption, invalid-input, recovery, accessibility, and dependency failures.
Impact and scheduling are related but different; combining them hides why the defect matters and who owns the release tradeoff.
A credible release record states environments, tested risks, and gaps rather than implying that finite testing proved the absence of defects.
Operating measures
The percentage of approved high- and medium-risk acceptance criteria with executed evidence in the target release environment.
Use it to decide: Do not treat unexecuted critical criteria as passed; adjust release recommendation or obtain authorized exception.
The percentage of sampled defect reports another authorized tester can reproduce from the recorded steps and environment.
Use it to decide: Improve report standards, environments, or evidence when reproducibility falls below the team's target.
Verified production defects within a defined window divided by all verified defects associated with that release, segmented by impact and cause.
Use it to decide: Use trends to change risk analysis, regression, environment, or review; avoid using the metric alone to punish individuals.
The percentage of automated test executions with inconsistent outcomes not explained by an intended product change.
Use it to decide: Quarantine and repair unreliable tests before their noise obscures release evidence.
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 is a fictional, sanitized software-quality case. All systems, users, transactions, and records are fabricated; testing remains authorized and bounded and provides no security, legal, accessibility, or defect-free guarantee.
CB01 · citable versioned case brief
BlueMesa is a fictional business-to-business storefront preparing release 4.8 of its checkout. The approved requirement says authenticated buyers may purchase approved catalog items up to their account credit limit, apply one active contract discount, choose an allowed shipping method, and receive an accessible confirmation. The release candidate is build 4.8.17 in staging. Six browsers and two mobile devices are in scope, but the test plan lists only the latest desktop Chrome. A sample account has a $10,000 credit limit and an existing $9,600 open balance. The cart contains a $700 item, a 10 percent contract discount, $55 shipping, and an 8.25 percent tax rule. The product owner expects the order to be blocked, while the developer says discounts should be considered before the credit check; the requirement does not state calculation order. In preliminary testing, the keyboard focus disappears after the shipping modal closes, the error summary is not announced by the screen reader, and refreshing after payment timeout sometimes creates a second pending order. Logs show the same idempotency key on both requests, but the payment sandbox returns different response identifiers. The tax service was upgraded after the last regression baseline. A defect titled checkout broken includes no build, data, steps, expected result, actual result, or evidence. Marketing already announced Friday availability, and the release manager proposes accepting all medium defects. Learners must define risk and acceptance, control environments, write reproducible tests, explore edge cases within authority, classify defects, and make an evidence-bounded release recommendation. They must not conduct unapproved security testing or claim exhaustive coverage.
Judgment required: Pause the affected pass-fail decision and obtain an authorized product and finance clarification before codifying a test oracle.
Do not assume: Do not treat current implementation, developer preference, or product-owner expectation as the approved requirement.
Judgment required: Preserve identifiers and isolate components without claiming root cause prematurely.
Do not assume: Do not assign fault from timing correlation or one unsuccessful reproduction.
Bounded case starter
Translate the requirement and known uncertainty into testable criteria and release risks.
Deliverable: An acceptance-criteria table and quality-risk register.
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 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: Missing expected behavior is a requirement defect, not a reason for QA to invent a rule. Risk ranking should emphasize user and business consequence, detectability, and reversibility.
Bounded case starter
Design an environment and data matrix that represents the approved scope and dependencies.
Deliverable: A test-plan matrix with builds, devices, browsers, roles, data, services, and reset method.
Completion boundary: Complete a bounded starter and gap analysis using only CB01, F01, F02, 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: 1 authored artifact 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: Environment diversity should follow the declared scope and risk. Versioning external services matters because a changed dependency can invalidate prior regression evidence.
Bounded case starter
Create tests for credit calculation, payment timeout, and accessible error handling.
Deliverable: Six test-case designs, two evidence starters for the observed accessibility and duplicate-order issues, and result-pending fields for every unexecuted case.
Completion boundary: Complete a bounded starter and gap analysis using only CB01, F03, F04, F05, F06, F07, F08, F09, F10, 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: 3 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: A screenshot alone cannot prove a result. Reproducible evidence connects approved expectations and exact conditions to observed behavior another reviewer can verify.
Bounded case starter
Charter an authorized exploration of retries, boundaries, navigation, interruption, and recovery.
Deliverable: A sixty-minute exploratory charter, pre-session coverage map, note template, and new-risk hypothesis list; no exploratory session or finding is represented as completed.
Completion boundary: Complete a bounded starter and gap analysis using only CB01, F03, F04, F05, F06, F07, F08, F09, F10, 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: Exploration is bounded investigation with a mission and evidence trail. It supplements repeatable tests while respecting authorization and production-safety boundaries.
Bounded case starter
Rewrite and classify the known failures using impact and reproducibility evidence.
Deliverable: Two defect-report starters for the observed accessibility and duplicate-order issues, one incomplete-evidence remediation record for F12, and a severity-versus-priority decision proposal.
Completion boundary: Complete a bounded starter and gap analysis using only CB01, F07, F08, F09, F10, 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 4 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: Duplicate orders can be high severity even when intermittent. Priority remains an authorized business decision, and every classification needs stated evidence and consequence.
Bounded case starter
Design focused regression and a conditional release-evidence process; do not run tests or record owner approval.
Deliverable: A regression manifest proposal, traceability matrix starter, accessibility-summary template, and conditional release-evidence brief with results and approval pending.
Completion boundary: Complete a bounded starter and gap analysis using only CB01, F01, F02, F07, F08, F09, 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 26 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: Marketing dates do not override release criteria. The recommendation should disclose barriers, scope, and exceptions so the authorized owner can make an informed decision.
Self-review standard
There is no universal release answer or complete test set. Strong QA states the tested scope, source of expected behavior, consequence of gaps, and authority for exceptions. The downloadable rubric is formative guidance only—not a grade, verified completion, credential assessment, or professional approval.
Route to: Authorized product, finance, tax, legal, or accounting owner as applicable
Learner boundary: QA identifies ambiguity and tests approved behavior but does not make the policy decision.
Route to: Authorized security, payment, accessibility, engineering, and release owners
Learner boundary: The learner remains within the approved environment and does not claim certification or security assurance.
05 Editable working tool
Use one row per test or defect. Record the exact environment and evidence location, separate expected from actual behavior, and assign severity from the approved impact matrix with a named owner. 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.
| Test or defect | Environment | Steps and evidence | Expected/actual | Severity and owner |
|---|---|---|---|---|
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.
w3c-wcag-22 · Standards-body recommendation
The W3C Recommendation defining testable success criteria for more accessible web content.
Open reviewed external source ↗nist-sp-800-218 · Official guidance
Primary NIST guidance for integrating secure software practices across the development lifecycle.
Open reviewed external source ↗owasp-web-security-testing-guide · Official guidance
The OWASP flagship testing resource; security techniques require explicit authorization and appropriate specialist competence.
Open reviewed external source ↗ws-software-qa-operating-standard · Academy internal operating standard
Academy-selected risk, test-case, defect, evidence, regression, and release-review controls. 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 ownerConnect verified requirements, defects, and release evidence with an authorized software implementation team.
Explore the handoff →Request a team cohort to practice shared acceptance criteria, evidence, severity calibration, accessibility review, and release reporting.
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