# Audio course certificate problem **URL:** **Author:** ![markkeung](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/markkeung/32/64943_2.png) [@markkeung](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fmarkkeung)%5C **Post date:** [November 6, 2026, 10:14am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Faudio-course-certificate-problem%2F191507%2F1 "2026-11-06T10:14:43Z") The certificate generation website has error .. Any fixed schedule? ---
**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C **Post date:** [November 7, 2026, 3:18am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Faudio-course-certificate-problem%2F191507%2F2 "2026-11-07T03:18:06Z")
Hmm… from what I’ve found, there do seem to be some plausible ways to fix this, but as outside users we can’t really tell when Hugging Face might apply a proposed fix through a PR, or even whether a fix is planned at all… 🤔: * * * ## Short answer: I couldn’t verify a repair date I checked the [official Audio Course certification instructions](https://huggingface.co/learn/audio-course/chapter8/certification), the [certificate generator](https://huggingface.co/spaces/MariaK/Audio-Course-Certification), earlier reports in [its discussion #17](https://huggingface.co/spaces/MariaK/Audio-Course-Certification/discussions/17), and the related [Audio Course GitHub issue #247](https://github.com/huggingface/audio-transformers-course/issues/247). As of **November 7, 2026** , I could not find a publicly confirmed repair schedule, a maintainer-promised restoration date, or a verified alternative that issues and records an equivalent **official** certificate. That is a limit of the public evidence, not a claim that the maintainers have no plan. I’m another community member, not an HF maintainer. I cannot see the private checker, production credentials, complete certificate-button logs, or internal deployment schedule. Issue #247 does describe **concrete repair options** for the publicly visible progress-checking and Unit 7 assessment Spaces. Its author says they would be happy to open a PR, but the issue’s Development section showed **no linked branch or pull request** , and no milestone, when I checked. So I wouldn’t describe a proposed patch as an already submitted or accepted PR, or presume when HF might deploy one. Work elsewhere is still possible. Importantly, that issue does **not** by itself identify the failing line in the official certificate generator. ## The least burdensome next step You’ve already reported the same situation in [the certificate Space’s discussion #17](https://huggingface.co/spaces/MariaK/Audio-Course-Certification/discussions/17). I think that is the best existing place to watch for a response about **this generator**. There is little value in asking you to file the identical report again, repeat your assignments, or run a collection of debugging scripts. If the page opens and clicking **“Check if I pass and get the certificate”** changes the message/PDF/image outputs to **Error** , the highest-value next observation is the **first server-side exception for that button invocation** , which a maintainer can examine. The visible word _Error_ does not tell us whether the failure is the private grader, result decoding, PDF creation, certificate-record write, or output delivery. If the symptom is different, the short distinction is: - **The Space won’t load:** investigate build, startup, scheduling, or resource availability. - **The form loads, but the button raises Error:** start at the certificate callback and its first exception. - **The form gives an ordinary “You didn’t pass” result:** check the actual recorded assignment results against the stated requirements; that is not the same symptom as an exception. A timestamp and a redacted screenshot may help the owner find the corresponding event, if not already present in #17. There is no reason for a learner to share a private token or another participant’s data. The [published qualification rule](https://huggingface.co/learn/audio-course/chapter8/certification) is **three of four hands-on assignments for completion** , or **four of four for excellence**. Eligibility and availability of the certificate service are separate questions. ## Two related services, and a critical distinction A small public-source snapshot taken around **08:33 JST on November 7** reported the certificate frontend as `RUNNING` and the **public Progress** and **Unit 7 assessment** Spaces as `RUNTIME_ERROR`. These are dated status observations, not live button tests. A running frontend can still fail when somebody submits the certificate form. The [public Progress Space](https://huggingface.co/spaces/MariaK/Check-my-progress-Audio-Course) and [public Unit 7 assessor](https://huggingface.co/spaces/huggingface-course/audio-course-u7-assessment) are the subjects of [#247](https://github.com/huggingface/audio-transformers-course/issues/247). But the [official certificate app.py](https://huggingface.co/spaces/MariaK/Audio-Course-Certification/blob/3209836270fd8e71c384bb38c4495f5aa1b81589/app.py) calls **`MariaK/Check-Audio-Course-Progress`** , a _different, non-public_ checker, then creates a PDF/image and writes to a private certificate-holder dataset. The similarly named public Progress Space is **not the endpoint named in that callback**. This gives us a useful, non-blocking plan: there are source-level fixes worth considering for the **public** services, and several testable repair branches for the **official certificate** service. We can explain both without claiming that they share one cause or that one fix will automatically restore recognized certificates. The expanded notes below are primarily for anyone who wants to investigate the implementation. They are **not** a list of tasks for a learner waiting for their certificate. > **1. Public Progress and Unit 7: the concrete issue and repair choices** > > ### What the public issue establishes > > [GitHub #247](https://github.com/huggingface/audio-transformers-course/issues/247), opened July 2026, identifies a dependency on `huggingface-course/audio-course-u7-hands-on` and its `usernames.csv`. The issue reports a 404 and proposes two choices: **restore the dataset or intended access** , or **make the public applications tolerate unavailable Unit 7 data**. Its author’s diagnosis is grounded in inspectable code, but the exact reason for an inaccessible resource (deleted, private, revoked access, incorrect identifier, or wrong filename) still requires the relevant credentials and request details. > > The captured [original public Progress app.py](https://huggingface.co/spaces/MariaK/Check-my-progress-Audio-Course/blob/63362850ebc9922a8972c3392d7de38b9984a729/app.py) reaches the Unit 7 usernames download through a call to `certification(hf_username)` during UI construction. If that fetch raises without protection, the whole public Space can fail before a user can inspect otherwise unrelated Units 4–6. The failure of an optional or partly independent source should not have to prevent the rest of a progress page from rendering. > > The first repair path is **restore the authoritative Unit 7 dataset** , with the intended ID, permissions, file and schema. This is the most direct choice if the dataset should still exist and can be safely recovered. A successful HTTP read alone is insufficient; the actual CSV columns and recorded entries must match the intended grading contract. > > The second path is a **controlled fallback** : move the dependency out of eager startup or guard that particular read, preserve the results for Units 4–6, and mark Unit 7 **unavailable** , rather than _failed_ or _passed_, when its authoritative record cannot be read. An outline, not a production patch, is: > > ```python > def load_unit7_record(username): > try: > path = hf_hub_download( > repo_id="huggingface-course/audio-course-u7-hands-on", > filename="usernames.csv", > repo_type="dataset", > ) > return check_username_in_expected_csv(path, username) > except EXPECTED_UNAVAILABLE_ERRORS: > return {"status": "unavailable", "reason": "Unit 7 record inaccessible"} > > # Do not run a fragile remote fetch while defining the initial UI. > # Do not count "unavailable" as a pass or silently turn it into a fail. > > ``` > > Here `EXPECTED_UNAVAILABLE_ERRORS` and `check_username_in_expected_csv` are placeholders. A real fix must use the exception types of the installed Hub version, validate the CSV, preserve existing return formats, and avoid catching arbitrary programming errors. It should be tested with **(a)** Unit 7 unavailable and valid Units 4–6, **(b)** a valid Unit 7 roster, and **(c)** malformed data. A green UI with incorrect grading would not be a repair. > > ### Unit 7 has its own failure stages > > The captured [official Unit 7 assessor source](https://huggingface.co/spaces/huggingface-course/audio-course-u7-assessment/blob/17311be5c1ce9ed380e548a22a5cc5121d79193c/app.py) clones/pulls its roster, loads a language-ID model, tests a submitted public demo, then updates the roster if the demo passes. A repository 404/permission error and **“No space left on device”** during model download are different stages. [Unit 7 discussion #23](https://huggingface.co/spaces/huggingface-course/audio-course-u7-assessment/discussions/23) includes observations and a later re-interpretation across dates; it does not prove which operation is failing today. If disk really is exhausted, changing a dataset URL will not by itself free space. > > The [community Progress fork](https://huggingface.co/spaces/VoicesColeby/audio-course-progress-check-fixed) defers/guards the relevant Unit 7 fetch in its published source. The [community Unit 7 fork](https://huggingface.co/spaces/VoicesColeby/audio-course-u7-assessment-fixed) omits the official roster push. Those are useful examples of _isolation and local testing_, not evidence that the official assessor has written an accepted result or the certificate backend has recorded an official credential. A fork may be a prototype for a maintainer patch without being a replacement for the recognized certification path. > > ### What a PR could fix, and what it could not establish > > A public-code PR could guard the fetch or repair the dataset contract; the dataset might also be restored operationally. **Proposal, PR, merge, deployment and successful certificate issuance are distinct stages**. > > The current [issue #247](https://github.com/huggingface/audio-transformers-course/issues/247) explicitly offers to open a PR, but I did not see a linked PR or announced ETA on the issue. Even if the public Spaces were repaired tomorrow, the certificate app’s _separate private checker and record-writing stages_ would still need to work. That is why I would not promise that one particular public PR will fix the certificate button. > **2. Official certificate generator: where a repair might actually belong** > > ### The public part of the official call chain > > At the [captured certificate app.py revision](https://huggingface.co/spaces/MariaK/Audio-Course-Certification/blob/3209836270fd8e71c384bb38c4495f5aa1b81589/app.py), clicking the button invokes `certification(hf_username, first_name, last_name)`. The public code roughly does these steps in sequence: > > 1. `check_if_passed` creates a `gradio_client.Client` for **`MariaK/Check-Audio-Course-Progress`** using the configured `HF_TOKEN`, then calls `predict(username, fn_index=0)`. > 2. It assumes the prediction result is a local JSON file path, opens it, parses the `data` table with Pandas, and counts passed assignments. Three yields completion; four yields excellence. > 3. For a passing result, it draws on PNG templates and a font to generate a personalized image and PDF. > 4. It calls `add_certified_user`, which uses a private Hub dataset `MariaK/audio-course` and its `usernames.csv`, then commits the recognized certificate record. > 5. It returns a message, PDF filepath, image, and output-row visibility to Gradio. > > The most important implication is the _order_: the private scorer can work but the file stage fail; the file can be produced but the **record push** fail; the record can be committed but output postprocessing fail. All may look like generic **Error** in the browser. It is too early to identify any one of these as the present root cause. > > ### Branch A: private checker connection or prediction > > The callback actually names: > > ```python > checker = Client("MariaK/Check-Audio-Course-Progress", hf_token=HF_TOKEN) > result = checker.predict(username, fn_index=0) > > ``` > > If the **first exception** occurs here, the owner can inspect the **actual configured credential** , target Space ID, availability, API name/index, input signature, and network/API compatibility. A moved endpoint or changed signature needs a different fix from an unavailable Space or invalid secret. Replacing `fn_index=0` blindly is risky: it may still be correct, and the wrong index could invoke a different function. > > Our small unauthenticated probes against the private checker and two restricted datasets returned HTTP **401**. That is expected for many private resources and says nothing decisive about the **official Space’s configured token**. It does not demonstrate deletion or a credential failure in the actual certificate workflow. The safe maintainer check is a single authorized test of the documented endpoint with a controlled username, keeping token values and private grades out of public logs. > > ### Branch B: prediction-result type or schema > > The public source contains an assumption of this form: > > ```python > result = checker.predict(username, fn_index=0) > with open(result) as data_file: > payload = json.load(data_file) > frame = pd.DataFrame(payload["data"]) > > ``` > > The [Gradio changelog](https://www.gradio.app/changelog) documents a client-side change in the treatment of JSON outputs during the Gradio 4 transition: previously a downloaded JSON file path could be returned; newer contracts may return a Python object. **If** the private endpoint uses the affected component and **if** the certificate app now receives a mapping/list instead of a path, `with open(result)` is a plausible failure point. But neither the private component definition nor `type(result)` has been observed, so this remains a **conditional hypothesis**. > > The cheapest decisive check is the **result type and schema** , not anyone’s private grade: > > ```python > result = checker.predict(controlled_username, fn_index=0) > print(type(result). __name__ ) > # Inspect only safe structural metadata: mapping keys / container type. > # Compare against the private Space's declared API output component. > > ``` > > If the value is a valid file path, preserve appropriately checked file decoding. If it is a documented structured value, parse that structure directly. If it is a wrapper or another file-object shape, use the actual API’s contract. Validate the required `data` key, rows, field names, and pass-value representation before applying the 3/4 rule; malformed output must never become automatic success. I would **not** submit a generic `isinstance(result, dict)` patch without checking the private endpoint’s real schema and tests for both passing and non-passing users. > > ### Branch C: image, PDF, or file delivery > > The code uses certificate PNG templates and `Quattrocento-Regular.ttf` to render the name/date with Pillow, then saves an image and PDF. Those steps depend on working paths, readable files, write permissions, and the output file contract. The [certificate Space tree](https://huggingface.co/spaces/MariaK/Audio-Course-Certification/tree/main) includes templates, the font, and `fail.pdf`; mere _absence from the repo_ is therefore not a well-supported default explanation. > > The shared `certificate.pdf` filename may warrant per-request paths if concurrency becomes relevant. That is **preventive design** , not a proven cause; a PDF also does not certify that the record was written. > > For a non-passing result, the source returns a white placeholder image and a **zero-byte `fail.pdf`** while hiding the output row. The file exists; it is not a valid certificate PDF. If an actual traceback points to file postprocessing, the owner can test that path under the effective Gradio version, but a zero-byte placeholder is not enough to diagnose the button failure. > > ### Branch D: official dataset read/write > > For eligible users, the public app’s `add_certified_user` clones/pulls a **private `MariaK/audio-course`** repository, reads and updates `usernames.csv`, then pushes it back. A failure here can surface only after earlier grading and PDF operations have succeeded. The [Hub 1.0 migration guide](https://huggingface.co/docs/huggingface_hub/en/concepts/migration) documents removal of legacy `Repository`, while [current Hub upload guidance](https://huggingface.co/docs/huggingface_hub/en/guides/upload) provides supported update mechanisms. > > That does **not** prove this running Space uses Hub 1.0 or crashes on a removed import. Its public app imports `Repository` at startup; if the frontend is actually running under a compatible build, a top-level import failure is less consistent with a later button-only Error. The owner should match the first traceback, _effective_ `huggingface_hub` version, repo permissions, expected CSV schema, and actual read/push operation before deciding between pinning a compatible dependency, fixing access, or migrating the write path. > > Any change must preserve the intended official result: a validated eligible learner, the correct certificate tier, authorized and durable record update, and safe retries. Silently dropping a failed push to make a PDF download appear successful would create a false impression of certification. On the other hand, a successful push followed by a failed browser file delivery should not lead to duplicate or inconsistent records on retry. > > ### Branch E: returning values to Gradio > > The callback returns text, PDF, image, and visibility information. Errors can arise in output serialization after the handler logic runs. A common guess was that `output_row.update(visible=...)` no longer exists, but that is **contradicted** by [Gradio 5.6.0’s Row implementation](https://github.com/gradio-app/gradio/blob/gradio@5.6.0/gradio/layouts/row.py), which still defines it. The [README](https://huggingface.co/spaces/MariaK/Audio-Course-Certification/blob/main/README.md) declares Gradio `sdk_version: 5.6.0`. The declaration does not prove every effective installed version or successful file serving, but it defeats the simplistic “Row.update is missing in Gradio 5.6.0” diagnosis. > > The best default is therefore **one first server traceback** , then a narrowly chosen fix for the failing stage. The public code shows where to look; the private checker and official dataset require owner-level observations before anyone can say exactly which line to change. > **3. Decision tree: symptoms, evidence, and who can check what** > > The simplest diagnostic should identify the failing **stage** , not force the learner to reproduce a maintainer-only incident. This decision tree keeps the public and private branches distinct. > > ```plaintext > AT THE OFFICIAL CERTIFICATE SPACE: > > If the page does not load: > Check Space build/startup/runtime and scheduling logs. > Compare with historical infrastructure incidents only if symptoms match. > > If the form loads and reports an ordinary non-passing result: > Compare recorded assignment data with 3/4 or 4/4 criteria. > A normal negative result is not a generic server Error. > > If the form loads but the button produces Error: > Find the FIRST exception in that button invocation. > - Before/during private Client.predict: Space, token, API contract. > - While reading result/DataFrame: return type and result schema. > - During image/PDF work: asset paths, permissions, output file. > - During certificate dataset update: auth, CSV, clone/push. > - After Python returns: Gradio output postprocessing/serving. > Without that exception, do not select a specific root cause. > > SEPARATELY, IF PUBLIC PROGRESS OR UNIT 7 FAILS: > Inspect issue #247 and the public dataset/model-loading path. > Do not substitute this for a test of the private certificate checker. > > ``` > > For a **learner** , the minimal useful description is whether the form appears and _when_ Error occurs. If #17 already shows the symptom, even that question may be unnecessary. No one should need to expose their access token, private grading data, or actual certificate record to participate in the discussion. > > For a **community contributor** , checking fixed source revisions, actual PR/deployment state, and the authentication context of a 401/404 is useful. Static code cannot establish a live exception. > > For a **maintainer with access** , a short redacted observation would be enough to eliminate many hypotheses: certificate Space revision; effective Gradio/client/Hub versions; the first exception stage and class; whether an authorized private checker call succeeded; and, if appropriate, whether the certificate record commit completed. No tokens, names, or dataset rows need to appear in public. The captured renderer also prints the entered full name, so log excerpts should redact it. > > The key difference in acceptance criteria is equally important: a public progress UI can helpfully display “Unit 7 unavailable”; an official certificate must not treat an unavailable assessment as a pass, omit its authoritative record, or misrepresent an unofficial fork’s output as recognized completion. > **4. Version compatibility and runtime limits: conditional checks** > > Several visible APIs span more than one software generation. They are plausible engineering leads, but only a **versioned exception at the correct line** would make any one of them a diagnosis. > > | Source-level clue | What is supported | Cheap discriminator | What not to infer | > | --- | --- | --- | --- | > | Certificate README says `sdk_version: 5.6.0` | This is the _declared_ Gradio SDK configuration | Compare the deployed revision and installed `gradio` / `gradio_client` versions | It alone proves the exact runtime environment | > | `with open(result)` after private `predict` | The caller expects a JSON file path | Inspect controlled result **type/schema** , not private grade values | The private checker necessarily returns a dict today | > | `Row.update(visible=...)` | Exists in the [Gradio 5.6.0 Row source](https://github.com/gradio-app/gradio/blob/gradio@5.6.0/gradio/layouts/row.py) | If output serialization fails, inspect the _actual_ traceback/version | The generic migration note proves this method absent | > | `fail.pdf` | Exists in the public repo, **zero bytes** | If file serving fails, test postprocessing with a harmless local file | Its absence is the root cause, or zero bytes is a valid certificate | > | `huggingface_hub.Repository` | The [Hub 1.0 migration guide](https://huggingface.co/docs/huggingface_hub/en/concepts/migration) documents its removal | Check installed Hub version and the first failing import/clone/push | The running certificate frontend automatically uses Hub 1.0 | > | Public 401/404 and `RUNTIME_ERROR` | Access or service is unavailable **to that observer at that time** | Check request URL, auth context, Space and revision | Anonymous 401 proves an official token failed; status proves callback failure | > > The [Gradio Python client guide](https://www.gradio.app/guides/getting-started-with-the-python-client) and [changelog](https://www.gradio.app/changelog) help an owner inspect the API specification. In particular, the documented JSON-output contract change is a good lead **only if** the private endpoint uses that kind of output and the certificate caller receives an incompatible value. A type check is preferable to swapping between “open it as a file” and “treat it as a dict” by guesswork. > > Likewise, legacy Git-based Hub writes can be kept on a compatible pin as a short-term maintenance choice or migrated to [supported upload APIs](https://huggingface.co/docs/huggingface_hub/en/guides/upload) for the longer term. Either option needs tests for permissions, CSV schema, updates to existing usernames, safe retry behavior, and actual official record persistence. An API upgrade is not a reason to loosen grading or make a private dataset public. > > The [HF Spaces storage guide](https://huggingface.co/docs/hub/spaces-storage) matters if a current traceback shows disk/cache exhaustion. An old Unit 7 `No space left on device` log cannot establish today’s cause; disk, dataset access and scheduling require different remedies. > > Finally, public code and status are not runtime traces. A `RUNNING` frontend may fail after clicking; an anonymous 401 says little about the owner’s token; and a file in the repository may not resolve identically inside a container. None establishes successful official issuance. > **5. Similar reports: useful comparisons, not confirmed causes** > > Similar-looking Errors have had different causes at different times. The useful comparisons are: > > - **Closest, same interface:** [Certificate #17](https://huggingface.co/spaces/MariaK/Audio-Course-Certification/discussions/17) reports the message/PDF/image outputs showing Error in 2026. [#15](https://huggingface.co/spaces/MariaK/Audio-Course-Certification/discussions/15) and [#16](https://huggingface.co/spaces/MariaK/Audio-Course-Certification/discussions/16) contain other learner reports. They establish symptoms, not the failing line or individual eligibility. The Forum poster’s #17 comment is **not an independent second case**. > - **Earlier repair on the same Space:** in [certificate discussion #3](https://huggingface.co/spaces/MariaK/Audio-Course-Certification/discussions/3), an earlier Error was reportedly resolved after an owner restart, with user confirmation. This makes a restart a legitimate **conditional** option for a transient runtime failure, not a prescribed fix for 2026. > - **Related boundary, not the same runtime:** [certificate #9](https://huggingface.co/spaces/MariaK/Audio-Course-Certification/discussions/9) discusses a private checker from a copied environment; [Progress #4](https://huggingface.co/spaces/MariaK/Check-my-progress-Audio-Course/discussions/4) describes inaccessible certificate data in a clone. Neither validates the official token or current writeback. > - **Other branches:** [public Progress #9](https://huggingface.co/spaces/MariaK/Check-my-progress-Audio-Course/discussions/9) and [Unit 7 #23](https://huggingface.co/spaces/huggingface-course/audio-course-u7-assessment/discussions/23) concern public roster/model dependencies; [GitHub #191](https://github.com/huggingface/audio-transformers-course/issues/191) concerns old hardware scheduling. > > Each case is a candidate comparison **only if the failure stage and environment match** ; none identifies today’s private exception. > **6. Small verification steps and what a real fix should preserve** > > For maintainers, the smallest discriminator should precede any multi-service changes. These are **owner-side or controlled** tests, not learner homework. > > | First observation or controlled test | High-information outcome | Correct boundary | > | --- | --- | --- | > | One **first traceback** from the official button | Identifies private call, decoding, PDF, record write, or output serialization | Owner-only; redact personal and secret material | > | Actual deployed commit plus `gradio`, `gradio_client` and `huggingface_hub` versions | Tests whether a suspected migration applies | README is not a runtime-version proof | > | Public Progress with Unit 7 CSV unavailable, valid Units 4–6 | Shows the page can render partial results honestly | “Unavailable” cannot count as “passed” | > | Public Unit 7 dataset restored with expected CSV rows and assessor output | Tests read/schema/grading and, with authorization, writeback | A working fork may not update the official roster | > | Controlled private Checker call; capture type/schema only | Tests endpoint availability and parser contract | Do not log the actual grades or token | > | Harmless certificate template/PDF test and safe record-write test | Separates output file I/O from durable credential recording | A local PDF is not an official recorded certificate | > | Owner-approved official end-to-end test | Verifies recognized eligibility, record persistence, and downloadable PDF/image together | One success is not an all-users guarantee | > > These tests are **alternatives** , not a checklist everyone must complete. The first real traceback may eliminate most branches; then one focused repair and regression test are more informative than a speculative rewrite. > > ### The most important invariant: recognized credit > > The app writes its certificate record **before** returning the file/image, so two recovery cases matter: > > 1. **PDF exists, record push failed:** a downloadable file must not be presented as proof of a durably recognized credential. > 2. **Record committed, file delivery failed:** retrying should recover access without duplicate or inconsistent records. > > The code tries to replace an existing username row; preserve this intended idempotency. Neither a missing grade nor an unofficial fork should create recognized credit, and live certificate-record writes require owner approval. > > A useful owner update would distinguish **failure reproduced, change committed, correct Space deployed, end-to-end official issuance tested, and public ETA/status**. A merged PR or restored UI alone is not full certificate recovery. > **7. Source trail, evidence dates, and what would change this answer** > > For future readers, the main **primary sources** are: > > - **User report / official criteria:** [Forum #191507](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Faudio-course-certificate-problem%2F191507)%2C [Space #17](https://huggingface.co/spaces/MariaK/Audio-Course-Certification/discussions/17), [course certification guide](https://huggingface.co/learn/audio-course/chapter8/certification). > - **Specific code and public proposal:** [certificate app.py at captured commit](https://huggingface.co/spaces/MariaK/Audio-Course-Certification/blob/3209836270fd8e71c384bb38c4495f5aa1b81589/app.py), [public progress/Unit 7 issue #247](https://github.com/huggingface/audio-transformers-course/issues/247). > - **Conditional version evidence:** [Gradio changelog](https://www.gradio.app/changelog), [Hub 1.0 migration](https://huggingface.co/docs/huggingface_hub/en/concepts/migration). Other fixed-commit and history links are embedded in the relevant sections above. > > The **small-file source check** was on **November 7, 2026, around 08:33 JST** , capturing five Space revisions and verified archive checksums, **without private credentials or certificate submission**. Its anonymous 401 responses and runtime badges are time- and access-dependent. The Forum thread now displays the original question without a reply, but I could not freshly inspect #17; newer comments there remain possible. > > The answer should change for a confirmed ETA, a real PR/deployment, the **first official callback exception** , the private checker’s verified output schema, or an owner-approved end-to-end certificate and record test. These are different evidence levels. > > Until then: **the public assessment problems have proposed fixes, the certificate generator has testable but unconfirmed repair branches, and I could not verify a public restoration date.** I hope both paths can be repaired without compromising recognized credit.