Defines bounded architecture roles for routing, retrieval, transformation, reasoning, verification, policy, memory maintenance, and structured output without claiming that a compatible model exists.
Architecture guide: this topic defines a modular tiny-model planning contract. It does not claim that model artifacts exist, are compatible, or execute on this WordPress site.
Role before model
Start by naming the bounded function: route, retrieve, transform, reason, verify, constrain, maintain memory, or emit structure. Then define what evidence would show that a candidate model satisfies the role.
Minimum role contract
- Accepted input schema and maximum size.
- Produced output schema and confidence semantics.
- Supported domain and explicit out-of-domain behavior.
- Quality metrics and failure thresholds.
- Resource profile and concurrency limits.
- Data, privacy, policy, and authority boundaries.
Anti-pattern
Do not label a general model “legal,” “medical,” “security,” or another high-stakes role based only on fine-tuning claims. The role requires task-specific evaluation, limitations, and governance.
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?