Examines whether an SLM is the adaptive substrate, a bounded predictor inside a controller, or merely an auxiliary component, without assuming transformers satisfy teleodynamic commitments.
Research documentation: this page interprets a cited research source and defines evidence requirements. It does not claim a released Teleodynamic AI implementation.
Possible relationships
- Predictive substrate
- An SLM supplies predictions, embeddings, or scores while a separate controller maintains structural and resource dynamics.
- Adaptive component
- Only a bounded adapter, memory, routing graph, prompt policy, retrieval index, or rule layer changes; the base language model remains fixed.
- Full substrate
- The model architecture and parameters both change under the five commitments—a substantially harder and currently unverified case.
Recommended first architecture
Keep the SLM immutable and place a small, interpretable controller around it. Map H to routes, rules, memory entries, or adapters; θ to bounded scores or adapter values; E to a deterministic internal ledger; and τ to the append-only event history. This isolates the teleodynamic claim from ordinary model inference.
Candidate outer actions
- Add, retire, merge, or replace a routing rule.
- Create, consolidate, or evict a bounded memory item.
- Activate, replace, or retire a task adapter.
- Change a sparse expert or retrieval route.
- Select noop and preserve the current structure.
Inner dynamics
Inner adaptation can update controller scores, thresholds, calibration values, or a bounded adapter while the selected structural inventory remains fixed. The trace must make the fixed-structure window observable.
Do not conflate
Quantization, KV-cache eviction, context truncation, backend fallback, local inference, and thermal throttling are runtime resource-management techniques. They become evidence for Teleodynamic Learning only when they participate in the declared endogenous state transition and structural action space.
Failure criteria
The claim is unsupported when the SLM output alone determines all actions, when the resource ledger never changes action viability, when “structure” is only transient cache state, when candidate alternatives are not logged, or when freeze occurs only because a hard limit is reached.
Scope
This starter page defines the questions, boundaries, evidence, and failure modes that should be recorded before a capability is presented as supported.
Engineering considerations
- Identify the source, version, target environment, and owner.
- Separate observed values from estimates and externally reported values.
- Record trade-offs, unsupported cases, and fallback behavior.
- Link performance statements to a compatible benchmark methodology.
Verification questions
- What exact artifact, revision, backend, and environment were reviewed?
- Which assumptions could change the result?
- Which data should be retained so another engineer can reproduce the conclusion?