In plain English
This page explains where an AI behavior can live. It may be in a model, but it may also be in a prompt, memory record, adapter, dataset, tool setting, evaluator rule, or human workflow.
- Why this matters: AI risk can come from the whole arrangement, not one obvious model.
- What to look for: data, memory, routes, adapters, tools, evaluators, updates, and rollback paths.
- Technical version below: the expert terminology remains available and is linked through the glossary.
Edge Browser Ecology
Reports on tiny LLMs and browser execution show why small, modular AI can become a mainstream deployment pattern. Browser-side execution improves privacy and latency, but it also creates new composition and provenanceA record of where a component or behavior came from. Open glossary definition questions.
Tiny local models still need full composition evidence.
Privacy and low latency improve when inference moves to the browser, but local adapters, caches, service workers, and route decisions become part of the safety boundary.
Components
A browser ecology may contain a quantized tiny language model, LoRA adaptersA common kind of small adapter used to specialize large models. Open glossary definition, tokenizer, local cache, service worker, WebAssembly runtime, WebGPU path, IndexedDB store, router, prompt package, and UI-driven skill selection.
Risk shift
Client-side systems reduce server exposure, but they increase the number of local compositions. A user may load several skill modules, cache them, and later execute a different stack than the one originally evaluated.
Control pattern
Use signed manifests, immutable URLs, content hashes, explicit adapterA small add-on that changes or specializes model behavior. Open glossary definition compatibility, local permission prompts, no automatic unknown module loading, and a clear “reset ecology” operation that clears weights, adapters, memory, and caches.