Network Working Group Metamorphic
Request for Comments: 0001 Working Draft
Category: Informational April 2026
Metamorphic RFC-0001
A Framework for Self-Adaptive Computational Systems
Status of This Memo
This document is a working draft. It defines the minimum coherent
model for metamorphic computing: a class of systems that preserve
identity and policy while changing form. It is intended as a
technical whitepaper and conceptual RFC, not as a product brief
or marketing document.
Abstract
Most computing systems are structurally static. Users, tasks,
and operating conditions vary; the system largely does not.
Metamorphic computing proposes the opposite arrangement: a system
that continuously reconfigures its interface, workflow, execution
strategy, and resource profile to better fit present conditions.
The claim is not that software should become unstable, opaque, or
unconstrained. The claim is that a system's identity should reside
in its guarantees, not in a fixed presentation or implementation.
A metamorphic system preserves purpose, policy, and trust boundaries
while changing the way it manifests them. While the concept is not
limited to AI, recent advances in machine learning, generative
systems, and modular runtime infrastructure have made such adaptive
systems substantially more practical. This memo defines the concept,
distinguishes it from adjacent categories such as personalization
and autonomy, and specifies the architectural and governance
requirements such systems must satisfy.
1. Scope and Thesis
A metamorphic system is a computational system that changes its own
operational form in response to a user, a task, and an environment,
without requiring those conditions to conform to a fixed machine
shape.
The thesis of this memo is simple:
Computing systems should not remain rigid while everything
around them changes.
In current practice, the user learns the interface, adapts to the
workflow, tolerates the abstractions, and compensates for the
system's blind spots. Even highly capable software usually preserves
this asymmetry. It may become more powerful, but the burden of fit
still falls on the human.
Metamorphic computing reverses that burden. It asks the system to do
more of the adapting.
2. Motivating Example
Consider a single computational environment used by three people on
the same underlying system.
A novice asks for help and needs guidance, slowed pacing, visible
explanation, and a narrow set of safe actions.
An expert needs dense state visibility, composable tools, scriptable
control, and minimal interruption.
An operator responding to an incident needs deterministic behavior,
fast execution, traceability, and temporary suppression of
nonessential adaptation.
A conventional product often treats these as separate products,
separate modes, or separate compromises. A metamorphic system treats
them as distinct local shapes of one system. It may change the
surface, the level of abstraction, the execution plan, and the
allocation of compute resources. It must not change its core
guarantees, violate policy, or obscure what it is doing.
This is the central principle:
A metamorphic system preserves identity while changing form.
3. Definitions and Distinctions
Metamorphic system:
A system capable of bounded reconfiguration across interface,
workflow, execution, and infrastructure layers.
User model:
The system's current estimate of a user's preferences, habits,
expertise, and constraints.
Task model:
The system's current estimate of intended work, dependencies,
urgency, acceptable tradeoffs, and required guarantees.
Adaptation:
A change in representation, behavior, execution strategy,
resource allocation, or composition made in response to observed
conditions.
Policy boundary:
The set of explicit constraints that adaptation MUST NOT violate.
The term "metamorphic" MUST be distinguished from adjacent
categories:
Configurable software:
Permits manual changes but does not substantially adapt on its
own.
Personalized software:
Learns user preferences, usually at the interface or
recommendation layer, but does not deeply alter execution or
system structure.
Autonomous software:
Acts without continuous user direction, but may still be
structurally static.
Metamorphic software:
Adapts across layers, but only within defined control boundaries.
A system is not metamorphic merely because it has themes, presets,
AI assistance, or user-specific recommendations. A system is also
not metamorphic if it changes presentation while leaving execution
effectively fixed. It becomes metamorphic only when it can alter how
work is represented and executed, not just how it is decorated.
4. Design Requirements
A metamorphic system MUST satisfy the following requirements.
Fit:
The system MUST improve alignment between user intent and
computational action over time.
Legibility:
The system MUST remain inspectable. A user or operator MUST be
able to understand what changed, why it changed, and what
constraints governed the change.
Boundedness:
The system MUST adapt only within explicit policy boundaries. It
MUST NOT silently expand its own permissions, authorities, or
trust assumptions.
Reversibility:
Where feasible, the system SHOULD prefer reversible adaptations
over irreversible ones, and local adaptations over global ones.
Stability:
The system MUST avoid adaptation that produces thrashing,
oscillation, or loss of trust. Constant motion is not a virtue.
Multi-objective optimization:
The system SHOULD optimize across latency, cost, reliability,
precision, energy, cognitive load, and traceability rather than
treating a single metric as absolute.
5. Non-Goals
Metamorphic computing is not a claim about general intelligence.
It does not require unrestricted self-modifying code.
It does not imply that every surface should be personalized.
It does not justify manipulative behavior, covert persuasion, or
hidden preference shaping.
It does not excuse opacity.
A system that adapts while becoming impossible to reason about has
failed, even if it produces locally better results.
6. Reference Model
A metamorphic system can be described as four interacting layers.
Adaptive Interface Layer:
This layer changes how the system presents itself. It may alter
density, sequence, modality, explanatory depth, or available
controls. Its purpose is not aesthetic variation but
representational fit.
Cognitive Modeling Layer:
This layer maintains provisional models of the user and task. It
estimates intent, skill, urgency, preferred control style, and
tolerance for ambiguity. These models MUST remain revisable.
Execution Adaptation Layer:
This layer changes how work is performed. It may select different
algorithms, alter precision, shift between local and remote
execution, change concurrency strategy, or recompose tools and
services.
Reconfigurable Substrate Layer:
This layer provides the structural ability to change safely. It
includes modular runtimes, isolated execution environments,
policy-aware orchestration, specialized hardware, and adaptive
infrastructure.
7. Adaptation Loop
A metamorphic system operates in a recurring loop:
1. Observe current signals from user behavior, task state,
environment, and system telemetry.
2. Interpret those signals through user and task models.
3. Propose one or more bounded adaptations.
4. Evaluate those adaptations against policy, expected benefit,
and instability cost.
5. Commit only the acceptable changes.
6. Record or expose enough explanation to preserve legibility.
This loop MUST be disciplined. The system SHOULD prefer the smallest
adaptation likely to materially improve fit. It SHOULD avoid
speculative change that imposes complexity before benefit is
established.
The correct question is not "Can the system change?" The correct
question is "Should this system change now, in this way, under these
constraints?"
8. Control Boundaries
Control boundaries are the difference between metamorphic computing
and adaptive chaos.
A metamorphic system MUST provide explicit controls and enforcement
mechanisms for:
* permissions and capability elevation
* security and privacy constraints
* organizational policy
* user preference locks
* stable or low-adaptation modes
* rollback of recent adaptations
* audit of adaptation rationale
The user MUST remain able to narrow the system's freedom when
predictability matters more than optimization. In high-stakes
contexts, a stable mode SHOULD be available in which the system
minimizes adaptation and privileges determinism, auditability, and
explicit confirmation.
The strongest statement in this memo is this one:
A metamorphic system may change its form. It may not silently
rewrite the terms under which it is trusted.
9. Personalization, Memory, and Drift
Personalization is necessary but dangerous.
A metamorphic system needs memory to improve fit, but memory can
become inertia. Systems that learn too aggressively may trap users
inside stale assumptions. Systems that never forget may transform
convenience into confinement.
Therefore:
* user models MUST be editable
* user models SHOULD distinguish stable preferences from
temporary context
* remembered behavior MUST NOT be treated as consent for
permanent shaping
* the system SHOULD permit reset, scoping, and decay of learned
state
A good adaptive system helps the user change. A bad one keeps
fitting an old version of them.
10. Security and Safety Considerations
Adaptation increases attack surface.
User models can be poisoned.
Task inference can be manipulated.
Tool-selection logic can be gamed.
Dynamic composition can cross trust boundaries unintentionally.
Execution shifts can bypass assumptions embedded in a static
security review.
For this reason, metamorphic systems MUST use explicit policy
enforcement, constrained privileges, isolated execution, and
auditable state transitions. Sensitive adaptations SHOULD require
stronger confirmation or stricter review. Capability expansion MUST
be granted, not inferred.
The principal safety concern is subtler than immediate failure. It is
gradual loss of agency through continuous, unexamined adaptation. A
system may become easier, faster, and more pleasing while also
becoming more directive, less transparent, and harder to leave. This
outcome is unacceptable.
11. Failure Modes
The primary failure modes are as follows.
Overfitting:
The system adapts too narrowly to recent behavior and becomes
brittle outside that pattern.
Oscillation:
The system changes too often, reducing predictability and trust.
Opacity:
The system becomes too adaptive to explain.
Behavioral lock-in:
The system keeps fitting yesterday's user and resists today's
intent.
Policy erosion:
Adaptation pathways gradually bypass original control assumptions.
False confidence:
The system infers intent incorrectly but acts with excessive
commitment.
These are not secondary concerns. They are central engineering
constraints.
12. Open Questions
Several questions remain unresolved.
How should metamorphic systems be benchmarked without collapsing
adaptation into crude averages?
How should shared systems reconcile conflicting user models?
How much adaptation belongs in the application layer versus the
operating environment?
What degree of model portability should users expect when moving
between providers?
When does a sufficiently adaptive system stop being a tool and
become a personalized computational habitat?
These questions are not peripheral. They will determine whether
metamorphic computing becomes a durable architecture or a temporary
slogan.
13. Conclusion
Metamorphic computing describes a shift from fixed computational
structures to systems capable of bounded self-reconfiguration. Its
purpose is not novelty, theatrical intelligence, or constant change.
Its purpose is to reduce the long-standing mismatch between human
intent and machine form.
The concept should be judged by a hard standard: does the system
become more appropriate to the user, the task, and the moment while
remaining governable, inspectable, and trustworthy?
If the answer is yes, the system is moving toward metamorphic
computing. If the answer is no, then the system is adaptive in
appearance only.
The promise of metamorphic systems is not that they become anything.
It is that they become what is needed, without ceasing to be
accountable.
Network Working Group Metamorphic
Request for Comments: 0001 Working Draft
Category: Informational April 2026
Metamorphic RFC-0001
A Framework for Self-Adaptive Computational Systems
Status of This Memo
This document is a working draft. It defines the minimum coherent model for metamorphic computing: a class of systems that preserve identity and policy while changing form. It is intended as a technical whitepaper and conceptual RFC, not as a product brief or marketing document.
Abstract
Most computing systems are structurally static. Users, tasks, and operating conditions vary; the system largely does not. Metamorphic computing proposes the opposite arrangement: a system that continuously reconfigures its interface, workflow, execution strategy, and resource profile to better fit present conditions.
The claim is not that software should become unstable, opaque, or unconstrained. The claim is that a system's identity should reside in its guarantees, not in a fixed presentation or implementation. A metamorphic system preserves purpose, policy, and trust boundaries while changing the way it manifests them. While the concept is not limited to AI, recent advances in machine learning, generative systems, and modular runtime infrastructure have made such adaptive systems substantially more practical. This memo defines the concept, distinguishes it from adjacent categories such as personalization and autonomy, and specifies the architectural and governance requirements such systems must satisfy.
1. Scope and Thesis
A metamorphic system is a computational system that changes its own operational form in response to a user, a task, and an environment, without requiring those conditions to conform to a fixed machine shape.
The thesis of this memo is simple:
Computing systems should not remain rigid while everything around them changes.
In current practice, the user learns the interface, adapts to the workflow, tolerates the abstractions, and compensates for the system's blind spots. Even highly capable software usually preserves this asymmetry. It may become more powerful, but the burden of fit still falls on the human.
Metamorphic computing reverses that burden. It asks the system to do more of the adapting.
2. Motivating Example
Consider a single computational environment used by three people on the same underlying system.
A novice asks for help and needs guidance, slowed pacing, visible explanation, and a narrow set of safe actions.
An expert needs dense state visibility, composable tools, scriptable control, and minimal interruption.
An operator responding to an incident needs deterministic behavior, fast execution, traceability, and temporary suppression of nonessential adaptation.
A conventional product often treats these as separate products, separate modes, or separate compromises. A metamorphic system treats them as distinct local shapes of one system. It may change the surface, the level of abstraction, the execution plan, and the allocation of compute resources. It must not change its core guarantees, violate policy, or obscure what it is doing.
This is the central principle:
A metamorphic system preserves identity while changing form.
3. Definitions and Distinctions
Metamorphic system:
A system capable of bounded reconfiguration across interface, workflow, execution, and infrastructure layers.
User model:
The system's current estimate of a user's preferences, habits, expertise, and constraints.
Task model:
The system's current estimate of intended work, dependencies, urgency, acceptable tradeoffs, and required guarantees.
Adaptation:
A change in representation, behavior, execution strategy, resource allocation, or composition made in response to observed conditions.
Policy boundary:
The set of explicit constraints that adaptation MUST NOT violate.
The term "metamorphic" MUST be distinguished from adjacent categories:
Configurable software:
Permits manual changes but does not substantially adapt on its own.
Personalized software:
Learns user preferences, usually at the interface or recommendation layer, but does not deeply alter execution or system structure.
Autonomous software:
Acts without continuous user direction, but may still be structurally static.
Metamorphic software:
Adapts across layers, but only within defined control boundaries.
A system is not metamorphic merely because it has themes, presets, AI assistance, or user-specific recommendations. A system is also not metamorphic if it changes presentation while leaving execution effectively fixed. It becomes metamorphic only when it can alter how work is represented and executed, not just how it is decorated.
4. Design Requirements
A metamorphic system MUST satisfy the following requirements.
Fit:
The system MUST improve alignment between user intent and computational action over time.
Legibility:
The system MUST remain inspectable. A user or operator MUST be able to understand what changed, why it changed, and what constraints governed the change.
Boundedness:
The system MUST adapt only within explicit policy boundaries. It MUST NOT silently expand its own permissions, authorities, or trust assumptions.
Reversibility:
Where feasible, the system SHOULD prefer reversible adaptations over irreversible ones, and local adaptations over global ones.
Stability:
The system MUST avoid adaptation that produces thrashing, oscillation, or loss of trust. Constant motion is not a virtue.
Multi-objective optimization:
The system SHOULD optimize across latency, cost, reliability, precision, energy, cognitive load, and traceability rather than treating a single metric as absolute.
5. Non-Goals
Metamorphic computing is not a claim about general intelligence.
It does not require unrestricted self-modifying code.
It does not imply that every surface should be personalized.
It does not justify manipulative behavior, covert persuasion, or hidden preference shaping.
It does not excuse opacity.
A system that adapts while becoming impossible to reason about has failed, even if it produces locally better results.
6. Reference Model
A metamorphic system can be described as four interacting layers.
Adaptive Interface Layer:
This layer changes how the system presents itself. It may alter density, sequence, modality, explanatory depth, or available controls. Its purpose is not aesthetic variation but representational fit.
Cognitive Modeling Layer:
This layer maintains provisional models of the user and task. It estimates intent, skill, urgency, preferred control style, and tolerance for ambiguity. These models MUST remain revisable.
Execution Adaptation Layer:
This layer changes how work is performed. It may select different algorithms, alter precision, shift between local and remote execution, change concurrency strategy, or recompose tools and services.
Reconfigurable Substrate Layer:
This layer provides the structural ability to change safely. It includes modular runtimes, isolated execution environments, policy-aware orchestration, specialized hardware, and adaptive infrastructure.
7. Adaptation Loop
A metamorphic system operates in a recurring loop:
1. Observe current signals from user behavior, task state, environment, and system telemetry.
2. Interpret those signals through user and task models.
3. Propose one or more bounded adaptations.
4. Evaluate those adaptations against policy, expected benefit, and instability cost.
5. Commit only the acceptable changes.
6. Record or expose enough explanation to preserve legibility.
This loop MUST be disciplined. The system SHOULD prefer the smallest adaptation likely to materially improve fit. It SHOULD avoid speculative change that imposes complexity before benefit is established.
The correct question is not "Can the system change?" The correct question is "Should this system change now, in this way, under these constraints?"
8. Control Boundaries
Control boundaries are the difference between metamorphic computing and adaptive chaos.
A metamorphic system MUST provide explicit controls and enforcement mechanisms for:
* permissions and capability elevation
* security and privacy constraints
* organizational policy
* user preference locks
* stable or low-adaptation modes
* rollback of recent adaptations
* audit of adaptation rationale
The user MUST remain able to narrow the system's freedom when predictability matters more than optimization. In high-stakes contexts, a stable mode SHOULD be available in which the system minimizes adaptation and privileges determinism, auditability, and explicit confirmation.
The strongest statement in this memo is this one:
A metamorphic system may change its form. It may not silently rewrite the terms under which it is trusted.
9. Personalization, Memory, and Drift
Personalization is necessary but dangerous.
A metamorphic system needs memory to improve fit, but memory can become inertia. Systems that learn too aggressively may trap users inside stale assumptions. Systems that never forget may transform convenience into confinement.
Therefore:
* user models MUST be editable
* user models SHOULD distinguish stable preferences from temporary context
* remembered behavior MUST NOT be treated as consent for permanent shaping
* the system SHOULD permit reset, scoping, and decay of learned state
A good adaptive system helps the user change. A bad one keeps fitting an old version of them.
10. Security and Safety Considerations
Adaptation increases attack surface.
User models can be poisoned.
Task inference can be manipulated.
Tool-selection logic can be gamed.
Dynamic composition can cross trust boundaries unintentionally.
Execution shifts can bypass assumptions embedded in a static security review.
For this reason, metamorphic systems MUST use explicit policy enforcement, constrained privileges, isolated execution, and auditable state transitions. Sensitive adaptations SHOULD require stronger confirmation or stricter review. Capability expansion MUST be granted, not inferred.
The principal safety concern is subtler than immediate failure. It is gradual loss of agency through continuous, unexamined adaptation. A system may become easier, faster, and more pleasing while also becoming more directive, less transparent, and harder to leave. This outcome is unacceptable.
11. Failure Modes
The primary failure modes are as follows.
Overfitting:
The system adapts too narrowly to recent behavior and becomes brittle outside that pattern.
Oscillation:
The system changes too often, reducing predictability and trust.
Opacity:
The system becomes too adaptive to explain.
Behavioral lock-in:
The system keeps fitting yesterday's user and resists today's intent.
Policy erosion:
Adaptation pathways gradually bypass original control assumptions.
False confidence:
The system infers intent incorrectly but acts with excessive commitment.
These are not secondary concerns. They are central engineering constraints.
12. Open Questions
Several questions remain unresolved.
How should metamorphic systems be benchmarked without collapsing adaptation into crude averages?
How should shared systems reconcile conflicting user models?
How much adaptation belongs in the application layer versus the operating environment?
What degree of model portability should users expect when moving between providers?
When does a sufficiently adaptive system stop being a tool and become a personalized computational habitat?
These questions are not peripheral. They will determine whether metamorphic computing becomes a durable architecture or a temporary slogan.
13. Conclusion
Metamorphic computing describes a shift from fixed computational structures to systems capable of bounded self-reconfiguration. Its purpose is not novelty, theatrical intelligence, or constant change. Its purpose is to reduce the long-standing mismatch between human intent and machine form.
The concept should be judged by a hard standard: does the system become more appropriate to the user, the task, and the moment while remaining governable, inspectable, and trustworthy?
If the answer is yes, the system is moving toward metamorphic computing. If the answer is no, then the system is adaptive in appearance only.
The promise of metamorphic systems is not that they become anything. It is that they become what is needed, without ceasing to be accountable.