Teleodynamic modular intelligence / Project guide
Compose intelligence by function, not bulk.
Choose a planning scale, the number of installed tiny models, the maximum active set, hyper-specialized skill roles, and an orchestration pattern. MiRust produces a transparent architecture handoff for a modular in-browser AI system without downloading or executing a model.
Core distinction
Installed capacity is not active compute
A modular system may cache many narrow specialists while activating only one or two for a request. The architecture should record N_total installed roles, K_active maximum active roles, and K_parallel concurrent roles rather than describing every downloaded model as simultaneously running.
Installed set
Controls download size, local storage, update surface, license inventory, provenance, and dependency resolution.
Active set
Controls resident weights, working buffers, context state, latency, and immediate power use.
Structural policy
Controls when the system may activate, deactivate, replace, retire, reserve, or choose no-op.
Planning tool only: this composer does not detect hardware, download weights, run inference, merge adapters, or verify model compatibility. It produces a transparent architecture handoff for the separately governed GGUF implementation project.
Three composition families
Separate model identity from the way capabilities are combined
Independent specialists
Each role has a separate artifact and may use a distinct architecture or tokenizer. Routing is explicit, but installed storage grows roughly with the number of specialists.
Shared base plus adapters
A common base remains resident while small, compatible skill adapters alter bounded behavior. Storage can be lower, but compatibility and interference become primary evidence requirements.
Hybrid mesh
Adapter-compatible language skills share a base while structurally different roles—such as retrieval, ranking, or verification—remain independent specialists.
Teleodynamic control layer
Every structural action must justify its cost
The composer expresses a local planning score rather than claiming autonomous self-maintenance: V(a) = expected task benefit − memory cost − latency cost − uncertainty cost. A candidate activation is accepted only when it is compatible, affordable, and more useful than no-op under the declared policy.
Sense the task and current envelope
Record the request class, available memory, active modules, latency pressure, uncertainty, and policy constraints.
Propose the smallest useful active set
Use a router, explicit pipeline, cascade, or committee policy to identify candidate roles.
Evaluate structural actions
Compare activate, deactivate, replace, retire, reserve, and no-op using decomposed costs and expected benefit.
Execute only in the implementation project
GGUF must verify exact artifacts, formats, licenses, compatibility, memory, latency, quality, rollback, and safety before running the plan.
Handoff boundary
The plan describes a target architecture; it is not a runnable bundle
The JSON output contains conceptual roles, transparent estimates, topology counts, resource policy, and warnings. It contains no model weights, source code, secrets, executable WebAssembly, or authority to publish a compatibility claim. Its three explicit limits are installed slots, resident active slots, and simultaneous parallel slots.