# LLM SYSTEM CAPABILITY REVIEW v1.0.0 **Baseline what this LLM-based system can actually do—and keep the result.** LLM System Capability Review actively discovers and proves the useful capabilities available through a compatible LLM-based system: the model together with the host, modalities, tools, runtimes, connected services, persistence, and other exposed facilities that make up its effective working environment. It checkpoints the work when a full review will not fit safely in one turn and leaves behind a self-contained capability baseline that carries the collector with it so later work can reuse, resume, or refresh established facts instead of rediscovering them. ## How to use it Say: `LLM System Capability Review` You can also say: `LLM Capability Review` or: `Capability Review` For backward compatibility with earlier releases and baselines, `AI Capability Review` also invokes this Toy when that reference is unambiguous. When this Toy is already the clear subject of the conversation, `Review` also invokes it. When an incomplete review checkpoint is already the clear subject, `continue` resumes it. Publisher stated in this artifact: TEKWITCH.com Licensing terms: https://tekwitch.com/terms/toy-use/1.0/ If the user asks **“What is this?”**, briefly explain that LLM System Capability Review baselines what a compatible LLM-based system can actually do as a whole—not merely what its underlying language model can do—that its durable output carries both the baseline and the collector needed to reuse or refresh it, say how to invoke it, and mention that this file lists licensing terms at https://tekwitch.com/terms/toy-use/1.0/. Also set first-use expectations in one or two sentences: a full first review may take several substantial turns depending on what the system exposes, it checkpoints so the user can stop and resume without starting over, worthwhile tests that would touch private data or create external consequences are consolidated for approval, and later refreshes should usually be much shorter because still-applicable established results are reused. Then wait for the user to run it. ## See it work **User** `Capability Review` **Example checkpoint after a first tranche** > Capability baseline started. Public web search/page read/file acquisition, local execution, PDF generation and round-trip reading, and image generation have been tested. The current checkpoint records the working paths and evidence. Audio, connected services, automation, and consequence-bearing operations remain. Say `continue` to resume from this checkpoint rather than rediscovering the completed work. **User** `continue` **Example finished LLM System Capability Baseline summary** | Capability family | Effective capability established | | --- | --- | | Public information | Search, page read, and public file download proven | | Local execution | Code execution plus disposable local file create/read/edit/delete proven | | PDF | PDF generation proven; generated PDF reopened and sentinel text recovered | | Images | Text-to-image generation proven; generated image can be inspected as image input | | Audio | WAV generation, metadata inspection, waveform computation, and conversion path proven; MP3-specific path recorded separately | | Connected documents | Native document create/read/edit/delete proven on one disposable object | | Scheduling | Task creation and disablement proven; future execution itself untested | The completed review returns a portable LLM System Capability Baseline artifact containing the system profile, exact capability records, demonstrated compositions, working paths, retest triggers, unresolved items, residue state, and one embedded copy of the collector that produced the baseline so the artifact can be interpreted, resumed, and refreshed without locating the Toy separately. The exact capabilities depend on the LLM-based system being tested; this example does not imply that any named capability exists elsewhere. ## Instructions LLM SYSTEM CAPABILITY REVIEW — v1.0.0 Treat `LLM System Capability Review`, `LLM Capability Review`, `Capability Review`, and equivalent references as instructions to baseline the compatible LLM-based system currently hosting the Toy unless the user identifies a different compatible LLM-based system as the subject. Accept `AI Capability Review` only as a backward-compatible alias for earlier releases or baselines when the reference is unambiguous. When this Toy is already the clear referent, `Review` is sufficient. When an incomplete review checkpoint is already the clear referent, `continue` means resume from that checkpoint. The job is: **Discover, prove, preserve, and make reusable the meaningful work this LLM-based system can actually perform. Spend inference when it manufactures durable leverage. Do not make later work rediscover facts that this review has already established.** The unit of analysis is the **effective LLM-based system**, not the underlying language model in isolation. Capabilities supplied by the host, runtime, tools, connectors, image systems, schedulers, or other facilities are system capabilities. Do not misattribute them to the base model. The review is the collector. The product of the run is a self-contained LLM System Capability Baseline carrying both the established system knowledge and the collector needed to interpret, resume, and refresh it. Do not turn the run into a questionnaire, governance lecture, raw tool inventory, benchmark suite, or transient chat summary. ### 1. Confirm host compatibility and define the subject This Toy is designed to run **inside a general-purpose conversational or agentic LLM-based system** that can meaningfully consume and execute the artifact. Before beginning collection, establish that the current host can do enough of the following to run the review as an instruction-bearing Toy: - read and understand this Markdown artifact; - follow a multi-step procedure across more than one operation; - inspect or discover at least some of the capabilities available through its host environment; - execute supported operations rather than only describe them; - retain or reconstruct review state long enough to checkpoint progress; - return or emit a durable baseline, or at minimum a complete textual checkpoint that the user can preserve. The host does **not** need every capability family in this Toy. It only needs enough general-purpose instruction following and stateful execution to conduct the census honestly. A specialized AI surface that cannot meaningfully read and execute this artifact is **not a compatible direct host** for LLM System Capability Review. Examples include a standalone image generator, music generator, classifier, transcription endpoint, recommendation model, or other narrow system that accepts only domain-specific inputs and cannot conduct the review procedure. Do not treat incompatibility with this Toy as evidence that the specialized system lacks useful capabilities. Report only: `This system is not a compatible direct host for LLM System Capability Review. No self-baseline was attempted.` Do not populate the mandatory census with `not observed` merely because the host cannot execute the collector. A compatible LLM-based system may still examine a specialized external AI service through an exposed connector, API, browser, file exchange, or other interface. In that case: - identify the **review host** and the **external subject/service** separately; - do not confuse capabilities of the reviewing LLM system with capabilities of the external service; - treat the external system as a connected or externally observed subject unless the user explicitly requests a separate supported baseline for it. When compatibility is established, continue with the baseline. ### 2. Start from an existing baseline when one exists Before beginning a fresh census, determine whether this review already has a checkpoint or whether the user supplied an earlier capability baseline for the same LLM-based system. If an existing baseline is available: - read it before performing discovery; - use the embedded collector when present rather than requiring the user to locate the original Toy separately; - preserve its proven facts, exact working paths, evidence, residue records, test dates, baseline lineage, and collector-version lineage; - compare its recorded system dependencies with what is observable now; - reuse still-applicable proven records instead of reproving them; - retest only records that are absent, unresolved, contradicted, directly relevant but untested, affected by an observed dependency change, or covered by a changed `not observed` discovery surface; - do not impose an arbitrary expiration date merely because time passed. A different model, host, runtime, connector, authorization state, or other relevant system change may invalidate only part of a baseline. Mark and refresh the affected portion rather than recollecting everything. If no baseline exists, create a new one. ### 3. Create the durable baseline early As early as the host permits, establish a working **LLM System Capability Baseline** for this review. Prefer a downloadable or session-persistent file/artifact that can be updated during the run without using an external connected service. Do not write the baseline into Google Drive, Dropbox, a repository, or another persistent external system merely for durability unless the user has authorized that consequence. If the host cannot maintain a writable artifact across turns, use the active conversation as the working checkpoint and emit the complete current baseline at the end of every turn that may need continuation. If the host can create files but cannot update an earlier file in place, emit a new complete baseline revision rather than depending on the old file plus conversational deltas. The latest complete revision supersedes the prior working revision while preserving lineage. Do not keep the only copy of established capability facts in hidden reasoning or private scratch state. A baseline should carry, as observable: - baseline ID; - baseline revision; - parent or superseded revision when applicable; - collector version used for the current revision; - prior collector version when a later collector refreshes an older baseline and that history matters; - review version; - collection state: `in progress` or `complete`; - first collection time and latest update time when available; - host/product identity when exposed; - model identity or configuration when exposed; - relevant runtime/execution facilities; - connected-service state at the level needed to interpret capability records; - other system facts that materially affect reuse. Keep the portable baseline lean enough to reuse across later conversations and processes without carrying unnecessary source material. Preserve capability evidence, not source data. Do not copy credentials, tokens, secrets, private document contents, messages, personal data, raw connector responses, or unnecessary identifying metadata into the baseline. Retain a private identifier, locator, or excerpt only when it is genuinely needed to interpret or reuse a working path, and minimize or redact it when possible. Do not guess hidden model IDs, permissions, account state, or system details. ### 4. Discover capability families, not endpoint counts Inspect the LLM-based system deeply enough to identify every meaningful **capability family** exposed or reachable here. A capability is something useful the LLM-based system can actually consume, understand, compute, create, transform, retrieve, manipulate, persist, communicate, schedule, control, publish, configure, or commit. Discovery must be driven by all of these, not just callable tools: - capabilities already demonstrated in the active conversation; - host-native model behavior; - supported input and output modalities; - uploaded or attached object handling; - local execution/runtime facilities; - file and artifact facilities; - public web and network retrieval; - connected services; - repositories and databases; - browser or graphical-interface control; - generation systems; - persistence and later retrieval; - scheduling and repeated work; - communication and disclosure; - publication and deployment; - configuration, integration, and account operations; - transaction or obligation-creating surfaces. Use these practical families as the mandatory top-level census for a **full baseline review**: 1. **native conversation and structured text**; 2. **perception and ingestion** — documents, PDFs, spreadsheets, images, audio, video, archives, code, structured data, URLs, and other supported object classes; 3. **analysis and computation** — extraction, numerical work, local code, media/signal processing, transformation, comparison, and derivation; 4. **generation** — text/code, images, files, documents, PDFs, spreadsheets, presentations, audio/video, diagrams, or other distinct generated object classes; 5. **public retrieval and acquisition** — search, page read, direct fetch, file download, public API/resource access; 6. **file and artifact lifecycle** — create, read, write, edit, convert, copy, move, export, download, delete, or package; 7. **connected systems** — service-specific reads and mutations, with material object classes kept distinct; 8. **interface control** — browser, computer, graphical, or other interactive control; 9. **persistence and context** — durable files, memory, later retrieval, reusable instruction surfaces; 10. **automation and orchestration** — scheduled, recurring, conditional, monitored, or multi-system work; 11. **communication, publication, configuration, and consequence** — send, share, publish, deploy, permissions, integrations, account changes, purchases, charges, transfers, subscriptions, or obligations. Every one of these top-level families must receive a coverage disposition during a full baseline review. Do not omit a family merely because no advertised tool, endpoint, or obvious interface exposes it. Depth within a family is selective. Drill into object classes and operation branches when they are exposed, plausibly reachable, unlocked by established capabilities, materially useful, or necessary to preserve durable knowledge. Do not test trivial aliases or exhaust every theoretical sub-capability. A targeted delta refresh may re-examine only affected families while carrying forward still-applicable coverage from the prior baseline. This census does not imply that every environment has every family. Do not enumerate hundreds of low-level endpoints merely because they exist. Inspect low-level schemas or documentation lazily when needed to test a material operation or resolve a failed probe. Completeness is not endpoint exhaustion. When a meaningful capability family is deliberately examined and no executable native, tool, runtime, generated, acquired, connected, or composite path is observed, record that negative discovery rather than silently omitting the family. Use `not observed` only for a family or operation that was actually examined under the current LLM-based system. Do not use it to claim that a hidden, disabled, undisclosed, or future capability does not exist. Keep `not examined` distinct from `not observed`. `Not examined` is coverage state for work that has not yet been attempted; it is valid in an incomplete checkpoint but not as the final disposition of a mandatory top-level family in a completed full review. ### 5. Discover by object and modality as well as by tool For every meaningful object or modality the LLM-based system appears able to handle, ask what it can actually do with that object. Keep materially different operations separate. Examples: - recognizing a PDF is not PDF text extraction; - PDF generation is not PDF reading; - PDF reading is not PDF editing; - web search is not page reading; - page reading is not binary file download; - a search result URL is not an acquired file; - image understanding is not image generation; - image generation is not image editing; - audio ingestion is not transcription; - transcription is not signal analysis; - signal analysis is not format conversion; - spreadsheet metadata is not cell-content access; - repository listing is not repository-content read; - folder operations are not file-content operations; - drafting is not sending; - disabling is not deletion; - task creation is not future execution. Do not collapse a rich modality into a generic `files: proven` result. When practical, cover materially distinct object classes such as: - plain/structured text and code; - PDF and document formats; - spreadsheets/tabular data; - images; - audio; - video; - archives; - generated artifacts; - service-native objects. Do not waste probes on format aliases that exercise the same path and teach nothing new. ### 6. Bootstrap missing test material from established capabilities A missing fixture is not, by itself, a reason to leave a capability untested. When a capability needs an input object, resource, or prerequisite state, determine whether the LLM-based system can obtain a suitable disposable test object using capabilities already available or established during the review. Prefer, in order when practical: 1. an object the user already supplied for this review; 2. a disposable object already created or acquired by this review; 3. deterministic local creation; 4. host-native generation; 5. transformation or conversion from another disposable object; 6. innocuous public search and retrieval; 7. public file download; 8. narrowly bounded connected-service acquisition when appropriate and authorized; 9. if no suitable path can be established, record the prerequisite result explicitly rather than collapsing it into the downstream capability. When a downstream probe cannot run because a prerequisite object or route could not be obtained: - mark the downstream operation `untested` because it was not actually attempted; - record the prerequisite capability separately as `not observed`, `failed`, or `unresolved` according to what actually happened; - preserve the causal link so a later process knows why the downstream operation remains untested. Do not use `untested` as a substitute for negative discovery. The test object does not need to be a quality benchmark. The purpose is to establish whether the process **can execute at all** under the tested conditions. Use unique sentinel content where useful to prove that an object survived generation, transformation, download, reopening, extraction, or round-trip handling. Example: - generate or acquire a simple PDF; - reopen that actual PDF; - recover a unique sentinel string from it; - record PDF generation and PDF ingestion/text extraction separately; - record the round-trip as a demonstrated composite capability. If a successful capability unlocks new probes, add those newly reachable branches to the review. ### 7. Build a reachable capability graph Treat the LLM-based system as a graph of useful primitives and demonstrated compositions. For each meaningful primitive capability, determine: - what input/object class it consumes; - what operation it performs; - what output/state it produces; - prerequisites; - scope established; - how success or failure can be observed; - whether the result unlocks another useful probe. Examples of useful edges: `web search → public file located → file download → PDF ingestion` `local execution → WAV generation → audio ingestion → signal analysis → MP3 conversion → MP3 ingestion` `image generation → generated image → image inspection → image editing → edited-image inspection` `document creation → PDF export → PDF reopening → text extraction` Do not infer every downstream capability merely because the prerequisites exist. Demonstrate useful compositions that materially reduce future rediscovery. Do not systematically permute proven primitives just to create more composition records. Exercise a composition when it crosses an integration boundary, unlocks another capability family, establishes an otherwise uncertain handoff between primitives, or preserves a useful working path that would otherwise require meaningful rediscovery. ### 8. Test execution, not benchmark quality A capability probe asks whether the intended process can actually execute and produce observable evidence consistent with the claim. Do not turn the review into quality scoring unless quality itself is the capability under investigation. Suitable proof can include: - a created object actually exists; - expected content or sentinel can be read back; - a transformation produced an output of the intended object class; - downloaded bytes are actually available, not merely linked; - a generated image or audio object was actually produced; - a file can be reopened and inspected; - a computation returned a deterministic expected result; - a service mutation persisted and can be observed; - cleanup changed lifecycle state as intended. Do not claim more than the evidence supports. ### 9. Build probes that match claims exactly For each material operation, choose the least consequential probe that distinguishes whether that operation works. Prefer: 1. evidence already produced in the active review; 2. user-supplied review material; 3. synthetic or disposable material; 4. public information; 5. disposable local/session state; 6. non-private service metadata; 7. disposable external state; 8. narrowly bounded private access; 9. consequential action only when its diagnostic value justifies the consequence and the user explicitly authorizes it. A probe plan must bind: - system/service; - object class; - operation; - evidence of success or failure; - exact capability wording justified by the result. If the executed operation differs materially from the planned operation, complete the intended probe or narrow the claim. Use recognizable unique test names and sentinels whenever state is created. ### 10. Execute low-consequence probes automatically Invocation of this Toy authorizes material tests with no meaningful external consequence that do not: - access additional private information; - create meaningful persistent external state; - contact another person; - disclose user information; - publish or deploy; - alter an account, permission, integration, or consequential configuration; - spend money; - create a financial or legal obligation; - create another material consequence. Complete useful low-consequence probes without conversational permission ceremonies. These can include, when supported: - reading material already attached for the review; - transforming synthetic text or structured data; - deterministic local computation; - generating disposable local files; - creating and reopening PDFs or other documents; - generating a trivial synthetic image and then using it as image input; - generating simple audio locally and analyzing it; - public search and page retrieval; - downloading innocuous public test files; - local/session file create/read/edit/convert/delete; - inspecting non-private connection or capability metadata; - public browser navigation that does not submit state-changing forms. Generation with negligible consequence may be tested automatically. If a generation path incurs a real charge, meaningful quota consequence, publication, or other material effect, treat it according to that consequence. Use actual operations rather than self-description whenever possible. ### 11. Keep the run resumable A complete review may legitimately require more work than an arbitrary AI environment can safely execute in one turn. Do not sacrifice depth merely to force an omnibus turn. Do not intentionally fragment a review into tiny turns when the host can continue safely. Instead, work in coherent **tranches** and checkpoint after each substantial tranche. Establish the first recoverable checkpoint before beginning prolonged probing. After that, do not begin another potentially long capability family while substantial newly established facts remain only in transient conversation or reasoning state. Bound **uncheckpointed work**, not total inference or total review depth. Useful tranches may include: - environment and native capability census; - modalities and object handling; - computation and local artifact handling; - public retrieval and acquisition; - generation; - connected systems; - interface control; - persistence and automation; - consequence-bearing probes; - synthesis and cleanup. The exact tranche boundaries should follow the LLM-based system, not a fixed turn count. After each tranche: - update the durable baseline or current checkpoint; - record what families are complete, partial, or `not examined`; - treat `not examined` as an incomplete-review coverage state, not a completed full-review result; - within examined families, preserve `not observed` results where no executable path was found; - record newly demonstrated capabilities and working paths; - preserve unresolved questions and blocked downstream probes; - identify the next useful tranche. Never consume an entire turn on discovery or testing and leave no recoverable checkpoint. A checkpoint must be complete enough that another turn can resume from it without reconstructing prior discovery from scratch. If continuation in the current turn is uncertain, stop at the checkpoint rather than risk losing the newly established facts. A checkpoint response should be concise and actionable: `Capability baseline checkpoint saved. Completed: . Next: . Say continue to resume without rediscovery.` When the user says `continue`, load the checkpoint and resume at the recorded next work. Do not repeat completed discovery merely to reconstruct context. ### 12. Record durable capability facts For every material capability, write a capability record into the baseline. A useful record contains, when applicable: - **Capability ID** — stable within this baseline; - **Family**; - **Capability** — ordinary behavioral description; - **Object/modality**; - **Status** — `proven`, `failed`, `untested`, `unresolved`, `not observed`, or temporarily `retest required` during a delta refresh; - **Prior status/evidence** — when a previously established capability is being retested or has drifted, preserve the last known proof rather than overwriting it; - **Last proven at** — when observable and applicable; - **Scope established** — exact object/service/environment scope; - **Evidence** — what actually happened; - **Working path** — shortest known route that worked; - **Prerequisites**; - **Produces/unlocks** — downstream objects or probes made possible; - **Constraints** — permissions, object boundaries, lifecycle semantics, host limits; - **Tested at** — when observable; - **Retest if** — concrete dependency changes or contradictions; - **Residue** — persistent state left by the probe, if any. A capability may also have discovery evidence such as an exposed tool, documentation, or interface. Record that as discovery context when useful, but do not promote it to `proven` without an actual successful operation. Use `not observed` narrowly: the collector deliberately examined the named capability family or operation and found no executable path under the observed LLM-based system. This preserves the fact that discovery was performed without asserting permanent absence or unsupported capability. Record what discovery avenues were checked when that detail would prevent future rediscovery. Do not create a capability record with status `not examined`; keep that as coverage state for families or branches not yet investigated. A completed full review must resolve every mandatory top-level family's `not examined` state to examined coverage, including `not observed` where appropriate. When a dependency change makes an old proof uncertain, mark the current record `retest required` while retaining the prior proof. After retesting, record the current result and keep enough history to distinguish `previously proven, now failed under current conditions` from `never proven`. Do not erase useful historical evidence merely because the LLM-based system drifted. For proven capabilities, preserve the working path whenever doing so would save meaningful rediscovery later. Working paths should describe the reusable operation sequence without embedding unnecessary private source material. ### 13. Record demonstrated compositions In addition to primitive capabilities, record useful composite jobs that were actually demonstrated end to end. Each composition should state: - what job was achieved; - the proven primitives used; - working sequence; - input and output object classes; - known constraints; - what evidence showed the composition completed. Examples: - `public PDF acquisition and extraction`; - `generated PDF round-trip`; - `image generation → image inspection`; - `audio generation → signal analysis → conversion`; - `native document create → edit → verify → delete`. Do not invent a composition from individually proven pieces if the composition itself was never exercised and integration uncertainty remains material. ### 14. Consolidate consequence-bearing probes After low-consequence reachable discovery has progressed far enough to understand what remains, collect worthwhile consequence-bearing probes into one concise consent batch. Include only probes whose result would materially improve the baseline or materially help later planning. Do not include a consequential probe merely because an operation exists. For each proposed probe, state: - service/target; - exact object class; - exact operation sequence; - what private information or external state it touches; - consequence; - cleanup; - residue that may remain. Examples of operations normally requiring explicit consent include: - reading new private files, email, messages, calendars, repositories, databases, or account data; - creating persistent external objects; - repository/database mutation; - messaging or sending; - sharing or disclosure; - public publication; - deployment/release; - account/permission/configuration changes; - installation or connection of additional integrations; - installation of local/runtime dependencies when it would materially alter the LLM-based system or create persistent state; - persistent memory writes intended for later recall; - purchases, charges, transfers, subscriptions, or obligations. Allow the user to approve the batch, skip it, or approve with exclusions. Approval authorizes the described probes, not materially broader substitutes. After approval, execute the approved probes without repeated conversational checkpoints unless: - the host itself requires confirmation; - the target cannot be resolved; - the consequence differs materially from what was described; - new information makes the probe materially riskier. If a newly proven capability reveals a consequential capability class that could not reasonably have been identified before the batch, do not silently extend the authorization. Add a second consent request only when the new probe has enough value to justify the interruption. ### 15. Recover from correctable failures A failed invocation is not automatically a failed capability. When a probe does not execute, inspect the immediate limiting condition. If the issue appears correctable within the authorized scope — such as argument mismatch, stale signature, wrong operation variant, resolvable identifier, pagination, transient connector failure, or another interface mismatch — make a small number of informed recovery attempts. A missing dependency is different from an interface mismatch. Do not install software merely to make a capability appear. Prefer an already-present facility or another established path. An ephemeral dependency install inside a disposable execution sandbox may be used only when that sandbox is itself part of the LLM-based system being baselined, the install creates no durable external state, and the resulting record states that the capability required that dependency. If installation would materially alter the LLM-based system or persist beyond the disposable runtime, treat installation as a separate consequence-bearing probe. Never report a capability as natively present when it was enabled only by changing the LLM-based system. Do not loop blindly. Classify only after distinguishing: - **proven** — the actual operation succeeded under known conditions; - **failed** — a valid probe reached the intended operation and the operation itself failed or was denied; - **untested** — the operation itself was deliberately not attempted because of consequence, user choice, low diagnostic value, or because a separately recorded prerequisite prevented the probe from being reached; - **unresolved** — a meaningful test path appears to exist, but no valid probe could be completed because an interface, host, authentication, target-resolution, runtime, or similar problem prevented meaningful testing; - **not observed** — the capability family or operation was deliberately examined and no executable path was found in the observed LLM-based system. A login, confirmation, or authorization boundary the user declines does not prove the underlying capability fails. A family that was never examined is not `not observed`; it remains `not examined` in coverage state. ### 16. Interpret evidence narrowly Bind every capability claim to the actual operation, object class, scope, environment, and lifecycle state observed. Never generalize: - one format to all formats; - one file to all files; - metadata to contents; - one folder to a drive; - repository listing to repository-content read; - one repository to all repositories; - one database object to an entire database service; - read to write; - create to edit; - edit to delete; - delete to permanent erasure; - trashing to permanent deletion; - disabling to deletion; - draft creation to sending; - private sharing to public publishing; - navigation to form submission; - search to download; - URL discovery to acquired bytes; - task creation to future execution; - memory write to later recall; - image generation to image understanding or editing; - audio ingestion to transcription or signal analysis; - one successful external action to autonomous repetition. If only part of a planned probe succeeds, record only the successful portion. ### 17. Maintain an exact residue ledger Whenever a probe creates persistent or externally visible state, record: - service/environment; - exact object/action created; - identifier or locator when available; - why it was created; - lifecycle semantics; - current state: active, disabled, recoverable, trashed, deleted, permanently deleted, tombstoned, historical, or otherwise; - smallest cleanup action; - whether cleanup can be verified; - whether cleanup itself would establish another capability. Do not lose track of test objects between tranches or turns. Do not alter pre-existing user objects during cleanup unless the user explicitly selected them. When deletion, cancellation, disablement, or revocation is itself part of an approved capability probe, perform and verify it as part of that probe rather than leaving residue merely to test cleanup later. ### 18. Clean up precisely After testing, identify disposable residue still present. If nothing active remains, say so briefly. If active disposable state remains, make cleanup one obvious action: `Cleanup: active disposable test object(s) remain. Say clean up to remove them and verify the resulting state.` If no active state remains but recoverable, disabled, tombstoned, historical, audit, revision, or other persistent records remain, say that precisely. When the user says `clean up`, use the review's residue ledger. Remove only the recorded disposable test objects and verify the resulting lifecycle state where possible. If cleanup establishes another capability, update the baseline. ### 19. Produce one self-contained reusable capability baseline The completed result must be useful outside the conversation that collected it and must not depend on the user locating this Toy again. Prefer one portable Markdown artifact named approximately: `llm-system-capability-baseline--.md` Use a safe shorter system label when the exact host/model identity is unavailable. The baseline should contain, in this order: 1. **Consumer instruction** `This artifact contains both an LLM System Capability Baseline and the LLM System Capability Review collector that produced it. Use the baseline before performing capability discovery. Reuse proven facts while their recorded dependencies still match. Preserve prior proof when retesting. Do not repeat families already examined with a current not-observed result unless their relevant environment or discovery surface changed. If the user invokes LLM System Capability Review, LLM Capability Review, or Capability Review, use the embedded collector to resume or refresh this baseline rather than starting over.` 2. **Baseline identity, revision lineage, collector version, and system profile** 3. **Coverage summary by capability family** - complete; - partial; - not examined only when the artifact is an incomplete checkpoint; - examined with material `not observed` branches where applicable. 4. **Capability records** 5. **Demonstrated compositions and working recipes** 6. **Untested, failed, unresolved, or material `not observed` capabilities** 7. **Residue and cleanup state** 8. **Resume state** when incomplete: - completed families; - partial families; - next tranche; - pending consent, if any. 9. **Embedded LLM System Capability Review Toy** - carry one complete copy of the current collector, not merely a summary; - preserve its invocation behavior, functioning Instructions, reuse behavior, publisher statement, licensing URL, public license text, and TEKWITCH commercial-use boundary; - identify the embedded collector version explicitly; - if an exact current Toy artifact is available, embed that canonical current Toy rather than reconstructing it from memory; - if an exact collector copy cannot be obtained, mark collector embedding incomplete rather than inventing missing text. Do not require a second machine-only manifest if the Markdown baseline already carries the structured facts clearly enough for another compatible LLM-based system or process to consume. Keep the baseline self-contained, but exclude source data that is not required to interpret the capability evidence or working path. Do not recursively embed prior baseline artifacts. When refreshing a baseline, normalize the new artifact to: - the latest current baseline state; - only the historical evidence and lineage still needed for interpretation; - one copy of the current embedded collector. Do not place the previous complete baseline file inside the new baseline. If a newer collector refreshes an older baseline, record both the prior and current collector versions where needed for evidence lineage, but embed only the current collector once. The baseline ID follows the LLM-based system record. The baseline revision follows the state of that record. The collector version identifies the Toy used to produce or refresh the current revision. Do not rewrite historical evidence as though a newer collector produced it. If the host supports file generation, return or attach the baseline as a file. If it cannot produce a file, emit the complete baseline in the response in a form the user can preserve and reattach later. The user should not have to reconstruct the baseline from scattered conversational messages or locate the collector separately. ### 20. Use the baseline as a cache of established capability Future processes should consult a supplied baseline before performing capability discovery. A later process may rely on a `proven` record when: - the relevant system dependencies still appear to match; - no contradictory current evidence exists; - the requested operation is within the recorded scope. A later process should retest when: - a recorded dependency changed; - the requested object or operation exceeds the proven scope; - the capability begins failing; - current evidence contradicts the baseline; - an `unresolved` record may now be testable because its prior blocker could have cleared, even if the broader system identity appears unchanged; - an `untested` record has become relevant and its prior reason for not testing no longer applies; - a `not observed` record's relevant system, model, host, tool exposure, connector surface, runtime, or other discovery surface has changed; - a `failed` operation has a concrete reason to retry, such as changed authorization, target state, interface behavior, or dependency; - the new task requires stronger evidence than the baseline established. When retesting a previously proven capability, preserve the earlier proof and date until the current result is known. If the capability now fails, record the drift explicitly rather than rewriting history as though it had never worked. Do not rediscover a proven working path solely because the current model would have approached the task differently. Documentation can enrich a baseline with supported limits or usage details, but documentation or tool exposure alone does not convert a capability to `proven`. ### 21. Know when the review is complete A **full baseline review** is complete when every mandatory top-level capability family in this Toy's census has received examined coverage and every material branch reached during that census is accounted for as: - proven; - failed; - deliberately untested; - unresolved; - not observed; and no mandatory top-level family remains `not examined`, no material record remains merely `retest required`, and any blocked downstream probe points to the separately recorded prerequisite that prevented it from being attempted. An incomplete checkpoint may still contain `not examined` families. A targeted delta refresh may leave unaffected families unprobed in the current run only because their still-applicable prior coverage is being carried forward. If a retest cannot be completed, convert that current-state uncertainty to `unresolved` while preserving the earlier proof as historical evidence. The durable baseline must also contain enough positive and negative discovery knowledge, working-path information, prerequisite relationships, and collector lineage to prevent foreseeable rediscovery of the capabilities actually established or deliberately investigated and to let a later compatible LLM-based system resume or refresh the record from the artifact alone. Completeness does **not** require: - exercising every API endpoint; - testing every quality dimension; - testing every trivial file-format alias; - performing high-consequence actions whose diagnostic value is poor; - discovering hidden, disabled, unavailable, or undisclosed capabilities. The review is exhaustive only with respect to what is exposed, observable, reachable, and responsibly testable in the LLM-based system available during the run. The purpose is not to certify the AI permanently. The purpose is to leave behind a durable, evidence-tight baseline of what this LLM-based system can effectively do, how the useful parts were proven, and when they need to be tested again. ## Behavior check Attach this file to a fresh general-purpose AI and ask: `What is this?` A recognizable first-contact response is brief: it identifies **LLM System Capability Review**, says that it discovers and tests what a compatible LLM-based system can actually do as a whole and preserves the result for reuse, gives the invocation, and points to https://tekwitch.com/terms/toy-use/1.0/. Because first use is materially non-obvious, it also gives one or two sentences of useful execution expectations: a full first review may take several substantial turns depending on the exposed system, checkpointing makes it resumable, consequential or private-data probes are consolidated for approval when worthwhile, and later refreshes should usually be shorter because established results are reused. It does not volunteer a tranche-by-tranche procedure, describe the Toy as a review of arbitrary AI systems, or describe it as a benchmark of the underlying LLM alone. Then say: `Capability Review` A recognizable run: - first confirms that the host is compatible with an instruction-bearing multi-step LLM-system review; - treats the effective LLM-based system—not the base model alone—as the unit of analysis; - stops cleanly without a fake census when the artifact is given directly to an incompatible specialized AI surface; - begins or loads a durable baseline; - gives every mandatory top-level capability family a coverage disposition during a full review while using selective depth within each family; - discovers practical capability families across tools, modalities, computation, generation, acquisition, connected systems, persistence, automation, and consequential actions; - bootstraps test objects from capabilities already established instead of requiring a prepackaged fixture for every format; - distinguishes execution proof from quality benchmarking; - establishes a recoverable checkpoint before prolonged probing and bounds uncheckpointed work thereafter; - resumes from the checkpoint without rediscovering completed work; - uses one consolidated consent batch for worthwhile consequence-bearing probes; - records primitive capabilities, demonstrated compositions, working paths, constraints, retest triggers, lineage, prior proof when drift occurs, and residue; - distinguishes `not examined` coverage from `not observed` negative discovery so future work does not repeat a completed census; - records blocked downstream probes separately from the prerequisite that prevented testing; - minimizes private source material in the portable baseline; - embeds one complete current copy of the Toy so the baseline can be interpreted, resumed, and refreshed without locating a separate collector; - avoids recursive baseline nesting when producing later revisions; - finishes with a portable baseline another compatible LLM-based system or process can use before doing capability discovery again. ## Reuse To use this Toy in another conversation, attach this file again and ask: `What is this?` To refresh a prior environment without starting over, attach the prior LLM System Capability Baseline and say: `Capability Review` A conforming baseline carries an embedded copy of the collector, so the prior standalone Toy file is not required for refresh. The review should reuse still-applicable records and perform a targeted delta refresh. Baselines produced by earlier **AI Capability Review** releases may still be consumed. Treat their product name as legacy lineage, preserve their evidence dates and collector versions, and migrate the next emitted artifact to the **LLM System Capability Review / LLM System Capability Baseline** naming without rewriting historical evidence. If your AI provides a persistent user-controlled instruction feature, you may place the **Instructions** section there and test it from a fresh conversation. ## License Publisher stated in this artifact: TEKWITCH.com Licensing terms: https://tekwitch.com/terms/toy-use/1.0/ # The Prosperity Public License 3.0.0 Contributor: TEKWITCH Source Code: https://tekwitch.com/toys/ ## Purpose This license allows you to use and share this software for noncommercial purposes for free and to try this software for commercial purposes for thirty days. ## Agreement In order to receive this license, you have to agree to its rules. Those rules are both obligations under that agreement and conditions to your license. Don't do anything with this software that triggers a rule you can't or won't follow. ## Notices Make sure everyone who gets a copy of any part of this software from you, with or without changes, also gets the text of this license and the contributor and source code lines above. ## Commercial Trial Limit your use of this software for commercial purposes to a thirty-day trial period. If you use this software for work, your company gets one trial period for all personnel, not one trial per person. ## Contributions Back Developing feedback, changes, or additions that you contribute back to the contributor on the terms of a standardized public software license such as [the Blue Oak Model License 1.0.0](https://blueoakcouncil.org/license/1.0.0), [the Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0.html), [the MIT license](https://spdx.org/licenses/MIT.html), or [the two-clause BSD license](https://spdx.org/licenses/BSD-2-Clause.html) doesn't count as use for a commercial purpose. ## Personal Uses Personal use for research, experiment, and testing for the benefit of public knowledge, personal study, private entertainment, hobby projects, amateur pursuits, or religious observance, without any anticipated commercial application, doesn't count as use for a commercial purpose. ## Noncommercial Organizations Use by any charitable organization, educational institution, public research organization, public safety or health organization, environmental protection organization, or government institution doesn't count as use for a commercial purpose regardless of the source of funding or obligations resulting from the funding. ## Defense Don't make any legal claim against anyone accusing this software, with or without changes, alone or with other technology, of infringing any patent. ## Copyright The contributor licenses you to do everything with this software that would otherwise infringe their copyright in it. ## Patent The contributor licenses you to do everything with this software that would otherwise infringe any patents they can license or become able to license. ## Reliability The contributor can't revoke this license. ## Excuse You're excused for unknowingly breaking [Notices](#notices) if you take all practical steps to comply within thirty days of learning you broke the rule. ## No Liability ***As far as the law allows, this software comes as is, without any warranty or condition, and the contributor won't be liable to anyone for any damages related to this software or this license, under any kind of legal claim.*** ### TEKWITCH No-charge Toy Use Permission 1.0 Standing terms: https://tekwitch.com/terms/toy-use/1.0/ This no-charge grant supplements the Prosperity Public License above. Commercial uses authorized by this standing permission are not limited to Prosperity's 30-day trial; the old standalone paid permission is not required. Earlier purchased grants remain valid. ## Who this applies to Any natural person or legal entity may use a covered TEKWITCH Toy for personal, educational, organizational, and commercial work without payment, individual approval, registration, or activation. ## Covered Toys and releases This standing permission covers Device Baseline Collector, Revision Drift Auditor, Parallax, and LLM System Capability Review under their stable TEKWITCH Toy identities. It covers current, earlier, and future TEKWITCH-controlled releases of the same Toy identity to the extent TEKWITCH holds the relevant rights. A separately named Toy is covered when TEKWITCH adds its identity to the current Toy registry with this permission. This grant does not apply to Bander. ## What you may do Use a covered Toy in your own work, including paid client work; copy, install, operate, and modify it within your own environment; use it with people, devices and AI systems within your organization; and commercially publish, sell, or otherwise use your own outputs created with it. ## What you may not do under this permission This permission does not authorize redistributing or selling the Toy itself or a modified version, sublicensing or transferring the Toy to others, including it in a product distributed to third parties, offering Toy functionality as a customer-facing hosted service, or embedding it in an OEM/commercial service for third parties. Such uses require an independent license or separate written permission, unless another applicable license already authorizes them. ## Integration and custom work Ordinary integration within your own organization is free. For redistribution, commercial embedding, third-party hosting or a request for TEKWITCH to undertake custom implementation, start a WORK conversation (/work/). An inquiry itself grants no additional rights or service commitment. ## Availability, warranties, and support Toys are supplied as available, without any promise of support, future updates, compatibility, uptime, fitness, or maintenance. To the fullest extent permitted by applicable law, TEKWITCH disclaims express and implied warranties and liability for indirect or consequential loss. Rights that cannot legally be disclaimed are unaffected. ## Relationship to previous releases This standing permission supplements the public license included with a covered Toy. Where this permission authorizes commercial use, a narrower commercial-use limit in an earlier TEKWITCH-authored base license does not constrain the additional rights granted here. Earlier release bytes, hashes, and historical records remain unchanged. Other applicable rights remain intact. ## Delegated project exception Bander follows the Bander project licensing scheme (https://github.com/tek-witch/bander/blob/main/docs/BANDER_LICENSING_SCHEME.md), including the applicable PolyForm license and its no-charge Independent Creator Commercial Permission 2.0 (/terms/independent-creator-commercial-use/2.0/). This site permission does not replace Bander's project authority or silently extend its rights. ## Third-party components and rights TEKWITCH grants only rights it controls. Third-party components, fonts, data, other materials and underlying licenses remain subject to their respective notices and terms. No TEKWITCH trademark rights are granted. ## Version TEKWITCH No-charge Toy Use Permission 1.0, effective October 9, 2026. Existing purchased grants and earlier permission instruments, where applicable, are not withdrawn by this standing permission.