A Functional Classification Test
Core Principle
A system is classified based on what it does at the moment it delivers content to a student, not how it is labeled, marketed, or implemented.
Part I: Instructional Actor Threshold Test (Binary Gate)
A system is classified as an Instructional Actor if all of the following are true:
1. Generates Novel Content at Runtime
Output is not pre-authored or fixed
Two students can receive materially different responses to similar prompts
2. Provides Explanatory or Decision-Guiding Content
Explains concepts, provides steps, evaluates reasoning, or advises actions
Not limited to retrieval or display
3. Lacks Pre-Delivery Institutional Control
No human or system acting on behalf of the institution determines the exact output before delivery
4. Influences Student Cognition Across the Interaction
Output shapes how the student thinks, reasons, or proceeds
Not a passive, bounded tool (e.g., calculator, static reference)
If all four conditions are met → Default classification: Instructional Actor
If any condition is not met → proceed to Part II.
Part II: Tool Qualification Test (All Required)
A system may be classified as a Tool only if it satisfies all of the following:
1. Bounded Output Space
Outputs are constrained, predictable, and enumerable
Behavior does not materially vary across users beyond defined parameters
2. Pre-Determined or Reviewable Content
Content is either pre-authored, or
Can be reviewed and approved prior to delivery
3. Full Reconstructability
Every interaction can be logged, replayed, and attributed
4. Institutional Control Over Outputs
The institution can constrain outputs and prevent disallowed content before delivery
5. Clear Binding of Responsibility
A single entity has authority over outputs
That entity is contractually and financially responsible
If any condition fails → the system cannot be classified as a Tool
Part III — Conditional Governance Requirements (Hybrid / Transitional Systems)
Core Rule
If a system exhibits any instructional actor characteristics, even partially, it must satisfy the corresponding governance conditions:
1. If the system generates variable or individualized outputs → Attribution + Reconstruction required
All interactions must be:
logged
reconstructable
attributable (see definition below)
2. If the system provides explanations, feedback, or guidance → Authority required
The institution must:
maintain institutional control over outputs at the point of delivery, or
restrict use to contexts where outputs are bounded and reviewable
3. If the system behavior is non-deterministic → Constraint required
The system must:
enforce limits on output behavior
prevent disallowed outputs before delivery
4. If outputs can influence student decisions or reasoning → Binding required
A responsible entity must:
formally accept liability for outputs
be contractually and financially accountable
5. If any of the above conditions cannot be met
The system cannot be deployed in student-facing use without elevated governance or reclassification as an Instructional Actor.
Behavior - Requirement
Variability Attribution
Guidance Authority
Non-determinism Constraint
Influence Binding
B. Model Substitution or Upgrade
Underlying system changes (e.g., LLM integration)
Behavior becomes non-deterministic
C. Loss of Reconstructability
Logs become incomplete or unavailable
D. Expansion of Use Case
System begins providing explanations, feedback, or guidance
E. Loss of Binding
Vendor disclaims outputs or no entity retains full responsibility
Part IV: Governance Implications (Non-Optional)
Classification determines required governance.
If Tool
Standard instructional governance applies
Policy and supervision may be sufficient
If Instructional Actor
The system must satisfy:
Attribution — identifiable responsible entity
Authority — control at generation
Reconstruction — full interaction logging
Binding — financial and legal responsibility
If these conditions are not met:
The system is operating as an instructional actor without an accountability structure.
Definition of Attribution
Attribution exists only if the institution can, for any specific student interaction:
Reconstruct the full interaction sequence
including prompts, system outputs, and relevant system state
Identify the system configuration
model/version or system state that produced the output
Distinguish between student-originated and system-generated content
Attach the output to a specific accountable entity
with both authority over the system and responsibility for its behavior
Failure condition
Attribution does not exist if any of the following are true:
Interaction sequences cannot be fully reconstructed
System behavior cannot be tied to a specific version or configuration
Outputs cannot be clearly separated from user input
No single accountable entity can be identified