A reference desk for AI model identities, versions, modalities, and the sources behind their claims. https://www.modelfactbook.com/ 2026-10-27T00:00:00Z https://www.modelfactbook.com/audio-model-task-map/ 2026-10-27T00:00:00Z Model Factbook Editorial

A practical vocabulary for identifying the audio task before interpreting model claims.

<p>Begin an audio model record with its input and expected output. Speech recognition, speech synthesis, audio understanding, and general audio generation answer different questions; one audio label does not make them interchangeable.</p> <h2 id="define-the-task-boundary">Define the task boundary</h2> <table> <thead> <tr> <th>Your intended task</th> <th>Input</th> <th>Expected output</th> </tr> </thead> <tbody> <tr> <td>Speech recognition</td> <td>A speech recording</td> <td>A transcript</td> </tr> <tr> <td>Text-to-speech</td> <td>Text and optional documented controls</td> <td>Generated speech</td> </tr> <tr> <td>Audio question answering</td> <td>Audio and a question</td> <td>An answer about the recording</td> </tr> <tr> <td>Text-to-audio</td> <td>A written description</td> <td>An audio clip matching the request</td> </tr> </tbody> </table> <p>These are working definitions for organizing research. A particular model may combine tasks, restrict inputs, or expose different interfaces. Check its own model card before assigning a capability.</p> <h2 id="record-conditions-before-comparing">Record conditions before comparing</h2> <p>Note the language, recording conditions, clip length, sample rate, channel count, and whether interaction must stream. For speech generation, record whether a reference voice is required, optional, or unsupported. Do not assume that a demo exposes every condition used to produce it.</p> <p>For synthetic speech, distinguish intelligibility, pronunciation, speaker similarity, prosody, and runtime behavior. A result on one dimension does not establish the others.</p> <p>This page proposes a vocabulary and contains no model ranking. Use <a href="/how-to-read-a-model-card/">the model-card checklist</a> to verify a concrete candidate.</p> https://www.modelfactbook.com/how-to-read-a-model-card/ 2026-10-27T00:00:00Z Model Factbook Editorial

A field guide to model identity, intended use, evaluation claims, and missing information.

<p>A model card is a starting point for understanding a model, not proof that it will work in your application. Read the exact card associated with the version you plan to use, then follow the linked technical sources.</p> <h2 id="start-with-identity">Start with identity</h2> <p>Record the publisher, repository URL, exact model identifier, and revision. A family name can refer to multiple checkpoints, sizes, or release generations. Keep the model, the company, the research team, and the hosting platform as separate entities.</p> <h2 id="separate-the-evidence">Separate the evidence</h2> <table> <thead> <tr> <th>Field</th> <th>What to record</th> <th>What remains to check</th> </tr> </thead> <tbody> <tr> <td>Intended use</td> <td>Tasks and users described by the publisher</td> <td>Whether your task matches those conditions</td> </tr> <tr> <td>Inputs and outputs</td> <td>Supported formats and documented interfaces</td> <td>Your actual language, file, and context requirements</td> </tr> <tr> <td>Evaluation</td> <td>Dataset, metric, baseline, and reported result</td> <td>Comparability and independent reproduction</td> </tr> <tr> <td>License</td> <td>The license linked to this version</td> <td>Whether your intended use is covered</td> </tr> <tr> <td>Limitations</td> <td>Known failures and exclusions</td> <td>Failures on your own representative examples</td> </tr> </tbody> </table> <p>Treat a missing field as unknown. Do not infer commercial permission from downloadable weights, or broad language support from one multilingual example. Store the source URL and the date you checked it.</p> <h2 id="turn-the-card-into-a-record">Turn the card into a record</h2> <p>Write one short paragraph for identity, one for documented capabilities, and one for limitations. Attribute unverified performance statements to their publisher. Keep your own test results in a separate section with the procedure and environment.</p> <p>Continue with <a href="/model-family-checkpoint-version/">model families and versions</a> before combining facts from different releases.</p> <h2 id="primary-reference">Primary reference</h2> <p><a href="https://huggingface.co/docs/hub/model-cards">Hugging Face: Model Cards</a> describes the model-card format. The checklist above is our proposed reading method.</p> https://www.modelfactbook.com/model-family-checkpoint-version/ 2026-10-27T00:00:00Z Model Factbook Editorial

How to avoid mixing facts from related model names, weights, releases, and hosted endpoints.

<p>The useful unit of a model fact is a specific artifact or documented endpoint at a specific point in time. A family name alone is too broad for a performance or compatibility statement.</p> <h2 id="use-a-compact-identity-record">Use a compact identity record</h2> <p>For a local checkpoint, save the repository, revision, weight variant, tokenizer or processor, runtime version, and configuration. For a hosted endpoint, save the provider, model identifier, documented version if available, request settings, and test date. Mark a provider-controlled version as unspecified when you cannot pin it.</p> <h2 id="avoid-accidental-transfers">Avoid accidental transfers</h2> <p>A claim about one checkpoint does not automatically apply to a smaller variant, quantized copy, fine-tune, API endpoint, or later release. A shared name also does not establish that two organizations have identical responsibilities.</p> <p>When sources disagree, retain both statements with their URLs and dates. Look for a release note or explicit owner clarification. Until that resolves the difference, label it as an open question rather than silently choosing the more favorable description.</p> <h2 id="a-useful-change-log">A useful change log</h2> <table> <thead> <tr> <th>Changed item</th> <th>Follow-up</th> </tr> </thead> <tbody> <tr> <td>Weights or revision</td> <td>Recheck task results and compatibility</td> </tr> <tr> <td>Runtime or processor</td> <td>Recheck output format and reproducibility</td> </tr> <tr> <td>API alias</td> <td>Record the date and check version documentation</td> </tr> <tr> <td>Model card or license</td> <td>Preserve the updated source and review affected claims</td> </tr> </tbody> </table> <p>Read <a href="/how-to-read-a-model-card/">the model-card guide</a> for the fields behind this record. This is a documentation method, not a claim about any particular model.</p>