Case packet

Neutral case identifier: case-2632bc38d6c3e7

The possible directed relationship from Artifact A to Artifact B is under review.

Artifact A

Reflective system

A reflective system contains a causally connected representation of itself that is available to its own processes, such that operations mediated through that representation can affect the system's subsequent behavior.

The structural core is the established term in computational reflection: a system that reasons about itself in a causally connected way, through structures that represent selected aspects of it — its self-representation. Commonplace applies the criteria relative to an explicitly declared boundary without prescribing whether human actors are included. Departures from the source literature are recorded under [Provenance].

Changing the boundary alone does not satisfy the definition. The representation must be available inside the boundary as a representation of that same system, not merely as telemetry or a control signal correlated with its state.

Scope

Calling a system reflective requires five things to be stated:

  • The system boundary—what processes, artifacts, and environment count as the system;
  • The represented aspects of that system and their granularity;
  • A self-representation that exposes those aspects;
  • Processes inside the boundary that can inspect or act through the representation; and
  • The causal connection by which changes in the represented aspects update the self-representation and representation-mediated operations affect later system behavior.

Reflection is therefore aspect-bound, not global. The terminology and granularity of the self-representation determine which questions and interventions the system can formulate about itself — Maes's theory-relativity point. No self-representation exhausts every possible aspect, although it may be complete relative to its declared set of represented aspects. A reflective architecture may also retain an unrepresented or unmodifiable kernel.

The following neighboring terms mark different capabilities:

Term Criterion
Self-description Information about the system is present, but need not affect operation.
Introspection A process can inspect or reason about represented system state.
Reflection The self-representation is causally connected to the represented system and participates in later operation.
Intercession Reflective access permits direct modification of represented system state or interpretation.

Intercession is a capability within reflection, but not every reflective architecture permits it.

No artifact authority family is required. A representation consumed as evidence or advice can mediate reflective change when it participates in the causal path into the represented organization; a nominal [system-definition artifact] that is not a self-representation cannot. The criterion is causal connection through a representation of the affected aspect, made precise by the consumer, channel, and force in [behavioral authority].

Retrieval-mediated causal connection

The causal connection need not be an interpreter or a compiler. Where the self-representation is a body of retained artifacts, it can run through discovery: a process searches the artifacts, finds the ones bearing on what it is doing, and derives its behavior from what it found. Retrieval is then the wire the representation acts along, and it is best-effort where a compiler is exhaustive — so [retrieval failure is reflection failure], which develops what that costs and how the wire is strengthened.

Exclusions

Reflection is not autonomy, successful self-improvement, formal verification, or closure under a set of recommendations. Nor is it organizational closure, the recursive regeneration of a network of component interactions, or autopoiesis, the narrower self-production of a living system ([Varela 1981, printed pp. 14–18; PDF pp. 1–5]).

Reflection is also not adaptation, and this is the misreading the term invites most. Both directions have occupants.

Reflection and intercession without adaptation. A Smalltalk image is the case to hold in mind. Classes are objects; methods can be added at runtime, superclasses changed, message dispatch intercepted, the compiler edited with the compiler. Implementation and self-representation are one structure, so the causal connection is as tight as it gets and intercession is total. Left alone, the image sits there for a decade and improves nothing — nothing in it notices that a method is slow, decides the change is worth making, or judges whether the rewrite helped. The programmer supplies the evidence-responsiveness. Remove the programmer and the improvement pathway is not weakened; it is absent. A reflective architecture permitting intercession supplies a causal path by which a system could change itself. It does not make any change responsive to evidence about an improvement objective — neither directly, nor through the search, evaluation, and operative retention that [a proposal-selection improvement loop requires].

Adaptation without reflection. Conversely, a system can improve itself with no self-representation at all. Ashby's Homeostat jogs its parameters to random values whenever its essential variables leave viable limits, holds the configuration that restores them, and so adapts — viability-driven, evidence-responsive change to its own organization ([Ashby 1960, chapters 7–8]). It is still not reflective, because nothing in it represents that organization. What it retains is a setting rather than a map, and [what that costs is addressability].

The two properties are orthogonal: reflection is structural, adaptation is a process, and each is available without the other. [Self-improving-system membership] is defined separately; this note owns only whether a named pathway routes change through a self-representation.

Misuse Cases

  • Calling documentation reflective because it describes the software that stores it, without showing a causal path into later operation.
  • Expanding the boundary after a failure so that any helpful outsider counts as an internal reflective component.
  • Calling a telemetry-driven controller reflective when its signal is not available inside the declared boundary as a representation of that same system.
  • Using reflexive and reflective interchangeably without identifying a distinct property that the new term would name.

Provenance and departures

The criteria above are inherited; the extensions are not. Collected here so the definition can be read as a definition, and so each departure is auditable in one place.

  • Causal connection, self-representation, theory-relativity — inherited. Maes defines a reflective system as a computational system that reasons about itself “in a causally connected way,” and names the structures representing selected aspects its self-representation ([Maes 1988, printed pp. 1–2, 14–17; PDF pp. 1–2, 14–17]). The introspection/intercession split is corroborated in [Wuyts and Ducasse 2001]; the embedded-self-theory lineage is [Smith 1984].
  • Retrieval as a causal connection — Commonplace's own. No source treats discovery over retained artifacts as the wire. See [retrieval failure is reflection failure].
  • Terminology reservation. Commonplace retains reflective system across boundary choices and reserves reflexive system for a future concept only if it names a distinct property. Nothing currently requires the second term.

Relevant Notes:

Artifact B

Actionable methodology

Actionable is the term this note defines. Methodology keeps its ordinary sense — guidance that maps represented conditions to a prescription, exclusion, ranking, or evaluation criterion, close to what information-systems scholar Shirley Gregor calls a Type V theory. A theory that only describes or explains, supplying nothing that discriminates among interventions, is not a methodology in that ordinary sense, however true it is; Commonplace does not additionally stipulate this as a technical condition, since the word already carries it.

A methodology is actionable for a particular operator, in a stated setting, when that operator can use its mapping to choose among available interventions in a target system. This is the operator-relative predicate Commonplace adds: a methodology nobody can apply here and now is still a methodology; it is simply not actionable in that setting. Actionability is a relation a methodology stands in, not a kind of artifact — there is no separate thing called an "actionable theory."

The relation requires four elements

  • A methodology that applies to the target and supplies an intervention-relevant mapping.
  • An operator, including any interpreter it relies on, that can follow the mapping with enough fidelity for the mapping's distinctions to change its selection.
  • A set of available operations for which the operator has the necessary access, resources, and authority in the stated setting.
  • A target system that those operations can reach and affect.

The operator may be a person, an organization, a trained model, deterministic software, or a combination of them. Within such an arrangement, the interpreter is the part that realizes the mapping from conditions to a selection among operations.

Scope

The ordinary sense of methodology used here starts from information-systems scholar Shirley Gregor's theory for design and action. Type V theory “says how to do something” by prescribing methods, techniques, or principles for constructing an artifact ([Gregor 2006, printed pp. 619–620; PDF pp. 10–11]); membership does not require a currently capable or authorized operator.

Actionable adds the operational relation Gregor's taxonomy does not carry. A design-and-action theory sitting unread in a paper remains prescriptive — it is still a methodology — but it is not actionable in a particular setting unless an operator can use its mapping through available operations on the target. Theory type and situated actionability therefore answer different questions; actionability is not a proposed sixth type in Gregor's taxonomy.

Prescriptiveness and actionability come apart in both directions. A software-architecture methodology can be actionable for a developer before the developer acts on it: it maps architectural conditions to component and interface choices, and the developer has the access and authority to make those changes. If the developer loses repository access, it remains a methodology but is no longer actionable for that developer in that setting — it is still prescriptive, but the operational relation fails. Conversely, repository access alone actions nothing if the theory supplies no intervention-relevant mapping for the software system — the relation's other elements hold, but there is nothing to act on.

Evaluation contributes to actionability only when its result can affect the selection, retention, or modification of an intervention. Retrospective analysis with no path into action may be informative, but it is not actionable in this sense.

Exclusions

Actionable is not a compliment: the mapping, operator, available operations, target, and setting must be identifiable, or the word is doing no work. Methodology is not a synonym for practical-sounding advice — a theory that only describes or explains is not a methodology, however true it is.

Actionability implies neither that the methodology is correct nor that an intervention will succeed. Gregor's “if acted upon” causal expectation remains conditional on the actor and setting ([Gregor 2006, printed p. 619; PDF p. 10]).

Misuse Cases

  • Calling a design paper actionable for an organization that lacks the access, resources, or authority to apply it.
  • Calling an instruction actionable without identifying the system and operations to which it applies.
  • Calling a classification actionable because a resourceful operator could invent a use for it, even though the classification supplies no intervention-relevant mapping.
  • Treating actionability as an intrinsic property of natural language, independent of an operator and setting.
  • Using actionable theory as a noun, as if actionability sorted artifacts into kinds rather than relating a methodology to an operator.
  • Predicating actionable of a methodology without linking to this definition. The bare word is common English with many unrelated ordinary uses (findings, edits, steps, guidance); the technical sense is licensed only where the occurrence links here, on "actionable" itself or on "methodology" in the same clause. An unlinked "actionable" is the ordinary word, not this relation.

Relevant Notes:

Under-review context phrase

an internal process may act through a methodology, but actionability alone does not establish reflection