This document defines an executability filter.
It is not a framework for:
- Determining truth.
- Predicting outcomes.
- Optimizing performance.
- Evaluating governance.
- Assessing legitimacy.
- Assessing persistence.
- Assessing robustness.
- Assessing scalability.
- Designing desirable systems.
- Classifying all possible abstractions.
- Explaining all emergent behavior.
- Discovering unknown mechanisms.
- Evaluating tacit, aesthetic, speculative, or exploratory representations before they are brought into executable specification.
Its purpose is narrower.
The filter asks:
Does a proposed abstraction possess the minimum structure required to make contact with execution within a bounded environment?
This is a minimum structural test.
Not a success test.
Not a quality test.
Not a persistence test.
Not a governance test.
Not a scaling test.
Not a test over all abstractions.
The filter is intended for abstractions that already aspire to execution-relevance.
That is, it applies to abstractions being asserted, proposed, evaluated, or refined as candidates for explicit execution.
It is not intended to evaluate every possible representation that humans can generate.
It is not intended to evaluate every emergent, tacit, latent, unknown, or not-yet-articulated structure.
The total space of possible abstractions is combinatorially vast.
Humans do not generate, attend to, or evaluate that space all at once.
We evaluate the abstractions that are produced, noticed, cared about, proposed, contested, or brought into specification.
The filter operates on that narrower candidate set.
It is designed to reduce the space of execution-aspiring claims by excluding abstractions that have not yet crossed from representation into executable causal structure.
It does not identify good systems.
It identifies whether a claim is execution-relevant at all.
The space of possible abstractions is effectively unbounded.
Ideas, goals, theories, strategies, policies, predictions, and coordination schemes can be combined in indefinitely many ways.
Most such combinations never reach execution.
They remain in a representational, speculative, exploratory, or pre-executable state.
Examples include:
- Policies with no identifiable executor.
- Strategies with no execution mechanism.
- Predictions with no propagation pathway.
- Goals with no transition model.
- Coordination schemes with no binding structure.
- Resource plans with no resource source.
- Institutional designs with no operating locus.
- Theories of change with no causal transition pathway.
- Optimization claims over variables that cannot be acted upon.
- Governance claims with no mechanism of instantiation.
- Aspirations that do not specify what changes.
- Programs that name outcomes but not executable units.
Such claims may be interesting.
They may be persuasive.
They may be true.
They may later become executable.
They may be part of discovery.
They may be useful before execution is specified.
But if they are being treated as execution-relevant, they must eventually specify how they enter the territory.
The filter exists to identify whether that condition has been met.
Its function is not to evaluate all dimensions of a claim.
Its function is to reduce the candidate space to those abstractions that possess at least one minimally coherent pathway into execution.
The filter is applied only to abstractions that are being treated as execution-relevant.
This includes abstractions such as:
- Proposed policies.
- Strategies.
- Institutional designs.
- Operational plans.
- Technical designs.
- Governance mechanisms.
- Coordination schemes.
- Theories of change.
- Optimization proposals.
- Control models.
- Implementation claims.
- Organizational reforms.
- Protocols.
- Algorithms.
- Procedures.
- Resource allocation schemes.
The filter is not applied to the total space of possible abstractions.
It is not meant to classify every thought, metaphor, vision, theory, artistic object, speculative concept, or emergent pattern.
Many abstractions may exist outside the filter's immediate domain.
Examples include:
- Exploratory ideas.
- Open-ended research questions.
- Aesthetic representations.
- Tacit practices.
- Informal habits.
- Emergent behaviors.
- Unknown mechanisms.
- Unknown unknowns.
- Latent possibilities.
- Early-stage intuitions.
- Descriptive theories not yet connected to execution.
- Representations whose executable relevance has not yet been asserted.
These are not rejected by the filter.
They are simply outside its target use until they are brought into explicit executable specification.
The filter is therefore an attention-management device.
It asks whether a candidate abstraction that already aspires to execution-relevance has enough specified structure to be evaluated as execution.
It is not a metaphysical partition of all possible abstractions.
The filter is grounded in a simple observation:
Representation alone is not execution.
A map may describe a route.
A theory may describe a system.
A model may describe a process.
A vision may describe a future.
A goal may describe a desired state.
A prediction may describe an expected outcome.
None of these, by themselves, imply that an executable pathway exists.
However, representations can participate in execution.
Policies, contracts, algorithms, control models, signs, protocols, interfaces, code, procedures, and institutional rules may all be representational structures.
They can become execution-relevant when they are embedded in a causal pathway that makes them operative.
Examples include:
- A policy linked to authority, enforcement, incentives, or administrative procedure.
- Code interpreted by a machine.
- A sign perceived by an actor and used to guide action.
- A contract linked to enforceable obligations.
- A model output connected to an operational decision.
- A protocol that constrains valid interactions.
- A control model coupled to sensors, actuators, and feedback.
The distinction is therefore not:
Representation versus execution as mutually exclusive categories.
The distinction is:
Representation alone versus representation embedded in executable causal structure.
The relevant first question is therefore:
Does the abstraction specify a realizable causal structure capable of producing at least one state transition within a bounded environment?
If the answer is no, further execution analysis is premature.
If the answer is yes, the abstraction has crossed the first boundary into execution relevance.
This does not mean it is true.
This does not mean it will work.
This does not mean it will persist.
This does not mean it is good.
It only means the abstraction is no longer merely representational.
The filter is a first-pass structural screen.
It is meant to answer:
Is this claim executable enough to be worth evaluating further?
It is not meant to answer:
Is this a complete system?
or:
Is this a good implementation?
or:
Is this robust under real-world conditions?
or:
Is this the best possible formulation?
The filter is deliberately minimal.
It asks for the smallest set of structures required for an abstraction to survive initial contact with bounded reality.
Additional structures may be necessary for higher-order evaluation.
Examples include:
- Observability beyond minimal execution.
- Feedback.
- Adaptation.
- Coordination topology.
- Incentive compatibility.
- Robustness.
- Resilience.
- Institutional legitimacy.
- Long-term resource renewal.
- Scaling dynamics.
- Comparative performance.
- Evaluator agreement.
- Error correction.
- Empirical validation.
These are important.
They are not all part of the first filter.
They belong to later analytical stages unless they are necessary for the claimed minimal transition to occur.
The purpose of the first filter is to separate execution-relevant claims from claims that remain in the brewing, aspirational, speculative, exploratory, or representational phase.
The filter uses a five-component structural decomposition:
- Execution locus.
- Resource basis.
- Transition model.
- Binding mechanism.
- Constraint surface.
It also requires a specified minimal executable unit.
This decomposition is provisional.
It is a contestable structural set.
It is not presented as a final ontology of execution.
It is not claimed to be the only possible decomposition.
It is not claimed to be scientifically complete.
It is not claimed to be immune to replacement.
A more coherent decomposition could replace it if it preserves or improves the filter's ability to identify executable contact.
The current decomposition is used because it captures a recurring pattern:
For execution to be specified, something must act, with some input basis, through some transition, under some stabilizing or realizing mechanism, within some bounded environment, at some evaluable grain.
The decomposition should therefore be judged by its usefulness as a first-pass structural filter, not as a final theory of all execution.
Execution occurs within a bounded environment.
A bounded environment is a domain with finite:
- Resources.
- Time.
- Information.
- Causal channels.
- Computational capacity.
- Cognitive capacity.
- Physical capacity.
- Organizational capacity.
- Perceptual capacity.
- Legibility.
- Authority.
- Attention.
A bounded environment also contains operative constraints.
These may include:
- Physical constraints.
- Economic constraints.
- Institutional constraints.
- Computational constraints.
- Informational constraints.
- Coordination constraints.
- Legal constraints.
- Cognitive constraints.
- Perceptual constraints.
- Interface constraints.
- Measurement constraints.
- Communication constraints.
The bounded environment defines the territory within which execution must occur.
Execution cannot be evaluated in an unconstrained space.
An abstraction that requires unbounded conditions is not merely difficult to execute.
It is structurally incompatible with execution.
The filter evaluates one question:
Can this abstraction be minimally instantiated as an executable causal structure?
In other words:
Can it cross the boundary between representation and execution?
Can it move from:
Representation
to
Executable state transition?
The filter does not evaluate whether execution will succeed.
It evaluates whether execution can be coherently specified at all.
The required threshold is intentionally low.
The abstraction does not need to define a mature system.
It does not need to be efficient.
It does not need to be durable.
It does not need to scale.
It only needs to specify enough structure for at least one claimed state transition to be causally instantiated within a bounded environment.
The filter deliberately excludes questions that belong to later analytical stages.
The filter does not ask:
- Is the abstraction correct?
- Is the theory accurate?
- Is the prediction true?
- Is the model empirically validated?
An executable model may be false.
A true statement may be non-executable.
Truth and executability are distinct questions.
However, this distinction has a boundary.
If an abstraction depends on assumptions that contradict the bounded environment required for execution, that incompatibility is relevant.
Examples include:
- Faster-than-light communication.
- Unlimited information.
- Infinite resources.
- Perfect coordination.
- Costless enforcement.
- Instantaneous adaptation.
- Action over variables that cannot be accessed or affected.
- Perception of signals by agents that cannot perceive them.
- Measurement of states that cannot be measured by the specified system.
- Authority exercised by no identifiable authority-holder.
The filter does not evaluate truth in general.
But it does reject assumptions that make execution structurally impossible.
The filter does not ask:
- Will the desired outcome occur?
- Will execution achieve its objective?
- Will benefits exceed costs?
- Will the plan work?
- Will the system perform well?
Success presupposes execution.
An abstraction can be executable and still fail.
The filter asks only whether execution can be instantiated.
The filter does not ask:
- Is the execution well designed?
- Is it efficient?
- Is it elegant?
- Is it robust?
- Is it safe?
- Is it adaptive?
- Is it optimal?
Quality presupposes executable structure.
The filter only asks whether the minimum structure exists.
A low-quality executable abstraction may pass.
A high-level but non-executable abstraction may fail.
The filter does not ask:
- Will execution continue?
- Will resources remain available?
- Will incentives remain aligned?
- Will adaptation remain effective?
- Will the system endure over time?
Persistence presupposes existence.
The filter may require a local binding or realizing mechanism sufficient to instantiate execution.
It does not require a mechanism that guarantees continued operation over time.
The filter does not ask:
- Who should possess authority?
- Which norms are legitimate?
- How should disputes be resolved?
- How should accountability be assigned?
- What governance structure is morally justified?
Governance presupposes execution.
The filter may identify whether some binding mechanism exists.
It does not evaluate whether that mechanism is legitimate, desirable, fair, stable, or accountable.
The filter does not ask:
- Will the system survive perturbation?
- Will it tolerate error?
- Will it recover from failure?
- Will it handle adversarial behavior?
- Will it remain functional across contexts?
Robustness presupposes executable structure.
The filter only tests whether a minimally executable structure can be specified.
The filter does not ask:
- Can this expand?
- Can this coordinate across larger domains?
- Can complexity remain manageable?
- Can the system preserve function at larger scope?
Scaling presupposes existence.
The filter asks whether execution can be instantiated at all.
It does not ask whether execution remains viable under expansion.
The filter does not ask:
- Could an unknown mechanism later be discovered?
- Could an emergent process later become legible?
- Could tacit practice later be formalized?
- Could a vague abstraction later become executable?
- Could an unknown unknown later become known?
Discovery may transform an under-typed abstraction into a well-typed one.
The filter does not deny that possibility.
It only evaluates the current specified structure.
The filter occupies the first stage of evaluation.
A useful sequence is:
Exist → Persist → Compose → Scale → Optimize
Where:
Exist asks whether execution can be instantiated.
Persist asks whether execution can continue over time.
Compose asks whether multiple executable systems can coexist and coordinate.
Scale asks whether execution remains viable under increasing complexity and scope.
Optimize asks whether performance can be improved under specified criteria.
This filter addresses only the first stage.
It is not a substitute for later stages.
It is a gate before they become meaningful.
For an abstraction to exist operationally, a coherent causal pathway from representation to execution must be identifiable.
The following structures must be specified.
Together they establish whether execution can be minimally instantiated.
There must be an identifiable locus through which state transitions occur.
Execution cannot occur in abstraction alone.
Execution must terminate in one or more concrete causal mechanisms.
Examples include:
- Individuals.
- Organizations.
- Software systems.
- Machines.
- Networks of interacting agents.
- Physical processes.
- Legal institutions.
- Markets.
- Protocols.
- Hybrid systems.
- Administrative procedures.
- Interfaces.
- Sensors and actuators.
- Contracts.
- Control systems.
At some point, something must perform or realize the transition.
Without an execution locus, execution is undefined.
Diagnostic question:
What entity actually performs or realizes the state transition?
Execution requires resources.
Resources are the inputs consumed, allocated, transformed, perceived, accessed, or required by execution.
Examples include:
- Time.
- Energy.
- Capital.
- Information.
- Attention.
- Material inputs.
- Labor.
- Computation.
- Authority.
- Access.
- Legibility.
- Measurement.
- Perception.
- Communication capacity.
- Interface access.
- Legal standing.
- Operational permissions.
Resources need not be sufficient for success.
They need not be sufficient for persistence.
They need not be sufficient for scale.
They need not support a complete system.
But they must be sufficient to instantiate at least the minimal executable transition being claimed.
Resource-free execution is ill-typed.
A claim that resources exist somewhere is not enough.
There must be an identifiable resource basis connected to the proposed execution pathway.
If the transition depends on perception, then the required signal must be perceivable by the specified execution locus.
If the transition depends on measurement, then the relevant variable must be measurable by the specified system.
If the transition depends on instruction, then the instruction must be accessible to the actor or mechanism expected to act on it.
Without a resource basis, execution has no input structure.
Diagnostic question:
What inputs are required, and where do they come from?
The abstraction must specify how states change.
A goal is not a transition model.
A vision is not a transition model.
A preference is not a transition model.
A prediction is not a transition model.
A value is not a transition model.
Execution requires identifiable transformations:
State A
→
State B
through specified actions, processes, or causal mechanisms.
The transition model describes how execution produces change.
Examples include:
- A person performs an action.
- An organization allocates resources.
- A software system updates state.
- A contract alters incentives.
- A machine transforms material inputs.
- A protocol routes information.
- A feedback loop modifies behavior.
- A legal rule changes permissible action.
- A control model updates actuator behavior.
- A sign changes navigation behavior when perceived.
- A classifier routes one case into one operational pathway.
The transition model does not need to be optimal.
It does not need to be complete.
It does not need to guarantee the desired outcome.
It only needs to specify at least one causal pathway by which the claimed execution occurs.
Without transitions, execution cannot be analyzed.
Diagnostic question:
By what process does State A become State B?
Execution requires a mechanism that stabilizes, enforces, compels, constrains, realizes, or otherwise makes the transition pathway operative.
The transition model describes how change occurs.
The binding or realizing mechanism explains why the specified transition can occur as specified rather than remaining merely optional, aspirational, or undefined.
Examples include:
- Authority.
- Incentives.
- Contracts.
- Protocols.
- Physical laws.
- Physical constraints.
- Automated enforcement.
- Feedback mechanisms.
- Dependency structures.
- Access controls.
- Institutional rules.
- Reputational penalties.
- Technical interfaces.
- Workflow permissions.
- Machine interpretation.
- Sensor-actuator coupling.
- Administrative mandate.
- Material coupling.
- Local causal necessity.
Intent alone is not binding.
Agreement alone is not always binding.
Description alone is not binding.
Preference alone is not binding.
Execution requires some mechanism through which the proposed transition is locally maintained, enforced, stabilized, constrained, realized, or made operative.
The mechanism does not need to guarantee persistence over time.
It does not need to be legitimate.
It does not need to be fair.
It does not need to be robust.
It only needs to explain why the transition can be instantiated at the moment or interval of execution.
This requirement is not a claim that all real-world behavior depends on explicit formal enforcement.
Emergent, tacit, exploratory, and weakly specified systems may execute in practice.
But when an abstraction is being evaluated as an explicit execution-relevant claim, the evaluator must be able to identify what locally realizes the transition.
Without a binding or realizing mechanism, the transition pathway dissolves into possibility rather than execution.
Diagnostic question:
What makes the proposed transition occur rather than remain optional, aspirational, unstable, or undefined?
Execution occurs within constraints.
Constraints define the boundaries that execution cannot violate.
Examples include:
- Physical limits.
- Computational limits.
- Organizational limits.
- Economic limits.
- Legal limits.
- Cognitive limits.
- Information limits.
- Coordination limits.
- Time limits.
- Energy limits.
- Perceptual limits.
- Measurement limits.
- Interface limits.
- Communication limits.
- Legibility limits.
- Authority limits.
- Accessibility limits.
Execution does not occur in an unconstrained space.
Constraint-free execution is ill-typed.
A valid execution structure must identify the operative limits within which the transition occurs.
Constraints do not need to make success likely.
They need not be fully modeled.
They need not define every failure mode.
They only need to define the bounded environment in which execution is claimed to be possible.
Observability and legibility enter the filter here when they are required for the claimed transition.
For example, a policy that requires people to read signs is not executable for actors who cannot perceive those signs unless some accessible signaling mechanism is supplied.
A monitoring system that depends on a variable no available system can measure is not executable as specified.
A control process that requires feedback no actor or machine receives is not executable as specified.
Without a constraint surface, execution is not situated in the territory.
Diagnostic question:
What limits bound the execution domain?
An abstraction must be evaluated at a specified grain of execution.
Some abstractions are too broad to evaluate directly.
Examples include:
- “Reform the education system.”
- “Align incentives.”
- “Improve governance.”
- “Coordinate society.”
- “Build a better economy.”
- “Make institutions more adaptive.”
- “Increase innovation.”
- “Solve misinformation.”
- “Improve collective intelligence.”
- “Optimize for public value.”
- “Increase trust.”
- “Make the organization more strategic.”
These may describe desired directions.
They do not, by themselves, specify executable units.
The evaluator must identify the smallest claimed executable unit.
Examples include:
- A school district adopts a curriculum.
- A department changes a procurement rule.
- A software system routes tasks according to a protocol.
- A contract changes payment conditions.
- A team reallocates decision rights.
- A machine transforms one input into one output.
- A policy creates an enforcement procedure.
- A platform demotes one content item according to one rule.
- A model output triggers one operational decision.
- A sign directs one actor through one accessible signal.
- A classifier routes one case to one queue.
- A procurement request under a threshold is routed to a departmental approver.
The minimal executable unit is the smallest bounded causal structure through which the abstraction claims to produce a state transition.
If no minimal executable unit can be identified, the abstraction is under-typed.
If the abstraction requires a minimal executable unit that violates bounded execution conditions, it is ill-typed.
The minimal executable unit is central to the filter.
It prevents the evaluator from analyzing an abstraction at a grain too broad to touch execution.
The existence of a representation does not imply the existence of an executable pathway.
Descriptions are not implementations.
Models are not executions unless connected to operative mechanisms.
Plans are not state transitions unless enacted through execution loci.
Goals are not mechanisms.
Predictions are not propagation pathways unless connected to action.
Preferences are not binding structures.
Policies are not execution unless connected to authority, procedure, incentives, enforcement, automation, or some other realizing mechanism.
Code is not execution unless it is interpretable by a machine in an operative environment.
Signs are not execution unless they are perceivable and behaviorally connected to actors or mechanisms.
The filter therefore asks:
How does this abstraction instantiate within the territory?
before asking:
Is it desirable?
or:
Is it correct?
or:
Will it work?
or:
Will it scale?
The burden is not merely to describe.
The burden is to specify a minimally realizable causal structure.
The filter produces three local component outcomes:
- Well-typed.
- Under-typed.
- Ill-typed.
These outcomes can be assigned to each required component.
The overall result is derived from the component vector.
Each abstraction should be evaluated across the following components:
| Component | Status |
|---|---|
| Minimal executable unit | Well-typed / Under-typed / Ill-typed |
| Execution locus | Well-typed / Under-typed / Ill-typed |
| Resource basis | Well-typed / Under-typed / Ill-typed |
| Transition model | Well-typed / Under-typed / Ill-typed |
| Binding or realizing mechanism | Well-typed / Under-typed / Ill-typed |
| Constraint surface | Well-typed / Under-typed / Ill-typed |
The aggregate rule is:
- If any required component is ill-typed, the abstraction is ill-typed.
- If no required component is ill-typed but at least one required component is under-typed, the abstraction is under-typed.
- If all required components are well-typed, the abstraction is well-typed.
This makes the classification explicit.
It also makes disagreement easier to locate.
Evaluators can contest the status of a component rather than only contesting the final classification.
A minimally coherent executable pathway can be specified.
The abstraction possesses:
- A minimal executable unit.
- An execution locus.
- A resource basis sufficient for minimal instantiation.
- A transition model.
- A local binding or realizing mechanism.
- A constraint surface.
A bounded causal pathway exists from representation to at least one executable state transition.
The abstraction is structurally executable.
This does not imply:
- Truth.
- Success.
- Efficiency.
- Persistence.
- Robustness.
- Legitimacy.
- Scalability.
- Desirability.
Only executability.
A well-typed abstraction may fail.
It may be false.
It may be inefficient.
It may be unstable.
It may be illegitimate.
It may be fragile.
It may not scale.
But it can be instantiated as execution.
Required execution structure is missing.
The abstraction may still be valuable.
The abstraction may be true.
The abstraction may later become executable.
However, execution analysis should be deferred until missing structure is supplied.
Typical symptoms include:
- Missing execution loci.
- Undefined resources.
- Unspecified transitions.
- Missing binding or realizing mechanisms.
- Undefined constraints.
- No minimal executable unit.
- Vague references to implementation.
- Reliance on intent without mechanism.
- Reliance on agreement without enforcement or realization.
- Reliance on goals without transition pathways.
- Reliance on prediction without propagation pathways.
- Reliance on optimization without actionable variables.
- Reliance on perception without accessible signals.
- Reliance on measurement without measurement pathways.
- Reliance on feedback without feedback channels.
The missing structure could, in principle, be supplied without altering the abstraction's core assumptions.
The abstraction remains incomplete with respect to execution.
An under-typed abstraction is not necessarily wrong.
It is not necessarily impossible.
It is structurally incomplete.
It remains in the brewing, exploratory, aspirational, or pre-executable phase.
The abstraction requires conditions incompatible with bounded execution.
Examples include:
- Infinite resources.
- Instant propagation.
- Unlimited information.
- Unlimited coordination.
- Costless consequences.
- Constraint-free action.
- Perfect knowledge.
- Frictionless adaptation.
- Enforcement without mechanism.
- State transitions without causal pathways.
- Resource consumption without resource sources.
- Coordination without communication or binding.
- Authority without a locus.
- Optimization over variables that cannot be observed or acted upon.
- Execution that requires the absence of operative constraints.
- Perception of signals inaccessible to the specified actor.
- Measurement of variables that cannot be measured by the specified system.
- Control without feedback where feedback is required.
- Action by entities with no access to the action channel.
In these cases the problem is not merely missing detail.
The required execution structure cannot be supplied without changing the abstraction's underlying assumptions.
The contradiction is structural rather than empirical.
Additional specification does not repair the abstraction unless the abstraction itself is reformulated.
The distinction between under-typed and ill-typed is important.
An abstraction is under-typed when required execution structure is missing but could plausibly be supplied without changing the abstraction's core assumptions.
An abstraction is ill-typed when the required execution structure contradicts bounded execution conditions.
The distinction can be stated as follows:
- Under-typed: the structure is absent.
- Ill-typed: the structure cannot exist as specified.
Examples:
-
“The organization will improve coordination.”
- Under-typed.
- The claim lacks execution structure, but structure could be supplied.
-
“All agents will instantly coordinate without communication, incentives, authority, shared information, or causal coupling.”
- Ill-typed.
- The claim requires conditions incompatible with bounded execution.
-
“The policy will work because everyone will read the posted signs.”
- Under-typed if the relevant actors, signs, environments, and perceptual conditions are unspecified.
- Ill-typed if the specified actors cannot perceive the signs and no accessible signaling mechanism exists.
-
“The system optimizes a variable that no actor, sensor, institution, or model can observe or affect.”
- Ill-typed.
- The claimed execution depends on an inaccessible variable.
When classification is ambiguous, the evaluator should mark the relevant component as contested rather than force false precision.
The component vector can represent this by adding notes.
Example:
| Component | Status | Note |
|---|---|---|
| Binding or realizing mechanism | Under-typed / contested | Voluntary compliance is asserted, but no stabilizing mechanism is specified. |
| Constraint surface | Ill-typed / contested | The claim appears to require information unavailable to the specified actors. |
To apply the filter, ask the following questions in sequence.
Identify the proposal, model, policy, strategy, theory of change, prediction, goal, or coordination scheme being evaluated.
If the abstraction is too broad, reduce it to a claimed executable unit.
Ask whether the abstraction is being proposed, asserted, or refined as something that should make contact with execution.
If not, the filter may not be the appropriate tool.
The abstraction may be exploratory, speculative, aesthetic, descriptive, or pre-specification.
In that case, do not classify it as failed.
Classify it as outside the filter's current target domain.
Identify the smallest bounded causal structure through which the abstraction claims to produce a state transition.
If no such unit can be identified, the abstraction is under-typed.
Identify the entity or mechanism through which the transition occurs.
Ask:
What acts?
If nothing acts, execution is undefined.
Identify the resources required for minimal instantiation.
Ask:
What inputs are required, and where do they come from?
If no resource basis exists, execution is undefined.
If the abstraction requires impossible resources, it is ill-typed.
Identify how State A becomes State B.
Ask:
What changes, through what causal process?
If there is no transition model, the abstraction is under-typed.
If the transition contradicts bounded execution, the abstraction is ill-typed.
Identify what makes the transition occur as specified.
Ask:
Why does the transition happen rather than dissolve into alternative behavior, remain merely aspirational, or remain undefined?
If no binding or realizing mechanism exists, the abstraction is under-typed.
If the abstraction requires binding without any possible mechanism, it is ill-typed.
Identify the limits within which execution occurs.
Ask:
What boundaries define the execution environment?
If constraints are unspecified, the abstraction is under-typed.
If the abstraction requires the absence of constraints, it is ill-typed.
Assign a status to each required component:
- Well-typed.
- Under-typed.
- Ill-typed.
Then derive the aggregate result.
Classify the abstraction as:
- Well-typed.
- Under-typed.
- Ill-typed.
- Outside current target domain.
Then stop.
Do not infer success.
Do not infer persistence.
Do not infer legitimacy.
Do not infer robustness.
Do not infer scalability.
Those belong to later stages.
The filter can be summarized as follows:
An abstraction is execution-well-typed if, within a bounded environment, it specifies a minimal executable unit, an execution locus, a minimally sufficient resource basis, a transition model, a local binding or realizing mechanism, and a constraint surface sufficient to instantiate at least one claimed state transition.
This is the minimum structure required for execution relevance under this filter.
The component set is provisional and contestable.
It may be revised if a better decomposition is found.
The filter can be understood as a search-space reduction device.
The universe of possible abstractions is vast.
Most possible arrangements of concepts do not form executable structures.
They may be meaningful.
They may be suggestive.
They may be rhetorically powerful.
They may later become executable.
But they do not yet define a causal pathway into action.
The filter operates like a parser for execution-aspiring claims.
It does not ask whether a sentence is true.
It asks whether the structure is sufficiently formed to be evaluated as execution.
The relevant search space is not the literal totality of all possible language strings or all possible abstractions.
That space is combinatorially too large to evaluate directly.
The relevant search space is the candidate set of abstractions that humans generate, notice, care about, propose, and bring into execution-relevant specification.
Within that candidate set, the filter reduces search by excluding claims that are not yet executable enough to justify more expensive evaluation.
The sequence is:
All generated or considered abstractions
→
Execution-aspiring abstractions
→
Execution-relevant abstractions
→
Persistent systems
→
Composed systems
→
Scalable systems
→
Optimized systems
The executability filter performs only the reduction from execution-aspiring abstractions to execution-relevant abstractions.
It discards claims that have not yet specified enough structure to survive initial contact with bounded reality.
The filter's reduction efficiency can be defined operationally.
Given a candidate set of abstractions submitted for execution-relevance assessment, the filter reduces the set by classifying abstractions as:
- Well-typed.
- Under-typed.
- Ill-typed.
- Outside current target domain.
A simple reduction measure is:
Excluded proportion = (under-typed + ill-typed + outside-domain candidates) / total candidates evaluated
A stricter measure is:
Execution-pass proportion = well-typed candidates / total candidates evaluated
Comparative reduction efficiency can be evaluated by comparing the filter against alternative filters over the same candidate set.
Relevant comparison criteria include:
- How many premature claims are excluded before costly evaluation?
- How many mature executable claims are preserved?
- How often do evaluators agree?
- How often are later-stage analyses wasted on under-specified claims?
- How often does the filter falsely exclude claims that later become well-specified?
- How much time or cognitive effort is saved before persistence, governance, robustness, scale, or optimization analysis?
The filter does not need to solve the full combinatorics of language.
It only needs to reduce the evaluated candidate set in a useful way.
The filter is expected to be most discriminative at the low-specification layer.
It is designed to reject vague, premature, or rhetorically powerful abstractions that are being treated as execution-relevant without executable structure.
Examples include:
- “Improve governance.”
- “Align incentives.”
- “Optimize for public value.”
- “Coordinate society.”
- “Reduce misinformation.”
- “Make the institution adaptive.”
- “Use AI to solve the problem.”
- “Build trust.”
- “Increase innovation.”
This is intentional.
The filter is not meant to finely rank mature implementations.
It is not meant to replace later evaluation.
Once a proposal already contains a clear execution locus, resource basis, transition model, binding or realizing mechanism, constraint surface, and minimal executable unit, the filter will often pass it.
That is not a failure.
It means the claim has crossed into the domain where later questions become meaningful.
The filter should therefore be judged by its ability to reject execution-irrelevant or under-specified claims early, not by its ability to evaluate complete systems.
The filter is primarily designed for known or partially known execution candidates.
It is most useful when the evaluator has enough structure to ask:
- What acts?
- With what resources?
- Through what transition?
- Under what realizing mechanism?
- Within what constraints?
- At what minimal executable unit?
This resembles distinctions sometimes made between:
- Known objects.
- Similar objects.
- Unknown objects.
- Unknown unknowns.
The filter is strongest for known and similar execution candidates.
It can sometimes handle unknown objects if enough structure is supplied to evaluate execution.
It cannot directly evaluate unknown unknowns.
Unknown unknowns may later become known.
Emergent mechanisms may later become legible.
Tacit practices may later be specified.
At that point they can enter the filter's domain.
Until then, the appropriate outcome is not failure.
The appropriate outcome is outside current target domain or under-typed, depending on whether execution-relevance is being asserted.
Claim:
“The policy will reduce misinformation.”
Evaluation:
- Minimal executable unit: unspecified.
- Execution locus: unspecified.
- Resource basis: unspecified.
- Transition model: unspecified.
- Binding or realizing mechanism: unspecified.
- Constraint surface: unspecified.
Component vector:
| Component | Status |
|---|---|
| Minimal executable unit | Under-typed |
| Execution locus | Under-typed |
| Resource basis | Under-typed |
| Transition model | Under-typed |
| Binding or realizing mechanism | Under-typed |
| Constraint surface | Under-typed |
Outcome:
Under-typed.
The claim may be desirable.
It may even be true.
But no executable pathway has been specified.
The claim remains pre-executable.
Claim:
“A platform will reduce misinformation by demoting posts flagged by a classifier, routing uncertain cases to human reviewers, and applying repeat-offender penalties under a published enforcement protocol.”
Evaluation:
- Minimal executable unit: one content item processed through the enforcement pipeline.
- Execution locus: software system, classifiers, reviewers, enforcement process.
- Resource basis: compute, training data, reviewer labor, policy staff, platform access.
- Transition model: content enters system, is classified, routed, reviewed, demoted, or penalized.
- Binding or realizing mechanism: platform rules, automated ranking changes, account penalties, reviewer workflow.
- Constraint surface: classifier accuracy limits, reviewer capacity, legal limits, latency, appeal process.
Component vector:
| Component | Status |
|---|---|
| Minimal executable unit | Well-typed |
| Execution locus | Well-typed |
| Resource basis | Well-typed |
| Transition model | Well-typed |
| Binding or realizing mechanism | Well-typed |
| Constraint surface | Well-typed |
Outcome:
Well-typed.
This does not mean the strategy is true, fair, effective, persistent, robust, or scalable.
It means an executable pathway can be specified.
Claim:
“All participants will instantly update their behavior once the optimal collective strategy is known.”
Evaluation:
- Minimal executable unit: depends on instantaneous universal coordination.
- Execution locus: unspecified or universal.
- Resource basis: unlimited information and attention implied.
- Transition model: instant behavioral update.
- Binding or realizing mechanism: absent or assumed.
- Constraint surface: effectively absent.
Component vector:
| Component | Status |
|---|---|
| Minimal executable unit | Ill-typed |
| Execution locus | Under-typed |
| Resource basis | Ill-typed |
| Transition model | Ill-typed |
| Binding or realizing mechanism | Under-typed |
| Constraint surface | Ill-typed |
Outcome:
Ill-typed.
The abstraction requires conditions incompatible with bounded execution.
It must be reformulated.
Claim:
“The organization will become more innovative.”
Evaluation:
- Minimal executable unit: absent.
- Execution locus: vague.
- Resource basis: unspecified.
- Transition model: absent.
- Binding or realizing mechanism: absent.
- Constraint surface: unspecified.
Component vector:
| Component | Status |
|---|---|
| Minimal executable unit | Under-typed |
| Execution locus | Under-typed |
| Resource basis | Under-typed |
| Transition model | Under-typed |
| Binding or realizing mechanism | Under-typed |
| Constraint surface | Under-typed |
Outcome:
Under-typed.
The goal describes a desired state.
It does not specify executable transition structure.
Claim:
“The machine converts electrical energy into mechanical motion through a motor.”
Evaluation:
- Minimal executable unit: one powered motor producing rotation.
- Execution locus: motor.
- Resource basis: electrical energy, material components.
- Transition model: electromagnetic interaction produces rotation.
- Binding or realizing mechanism: physical law and mechanical design.
- Constraint surface: voltage, heat, friction, load, material tolerances.
Component vector:
| Component | Status |
|---|---|
| Minimal executable unit | Well-typed |
| Execution locus | Well-typed |
| Resource basis | Well-typed |
| Transition model | Well-typed |
| Binding or realizing mechanism | Well-typed |
| Constraint surface | Well-typed |
Outcome:
Well-typed.
The claim may still fail in practice due to defective parts, insufficient power, or poor design.
But the abstraction is structurally executable.
Claim:
“The institution will optimize for public value.”
Evaluation:
- Minimal executable unit: absent.
- Execution locus: unspecified.
- Resource basis: unspecified.
- Transition model: unspecified.
- Binding or realizing mechanism: unspecified.
- Constraint surface: unspecified.
- Actionable variables: undefined.
Component vector:
| Component | Status |
|---|---|
| Minimal executable unit | Under-typed |
| Execution locus | Under-typed |
| Resource basis | Under-typed |
| Transition model | Under-typed |
| Binding or realizing mechanism | Under-typed |
| Constraint surface | Under-typed |
Outcome:
Under-typed.
The claim names an objective.
It does not specify what acts, what is measured, what changes, or how optimization enters execution.
Claim:
“The procurement office will reduce approval delay by automatically routing purchases under €5,000 to departmental approvers instead of central review.”
Evaluation:
- Minimal executable unit: one purchase request under €5,000 routed to a departmental approver.
- Execution locus: procurement workflow system and departmental approvers.
- Resource basis: existing software access, purchase records, approver authority, staff attention.
- Transition model: purchase request enters system, amount is checked, eligible requests are routed to departmental approval.
- Binding or realizing mechanism: workflow rule, approval permissions, institutional procurement policy.
- Constraint surface: spending threshold, legal procurement rules, system permissions, approver availability.
Component vector:
| Component | Status |
|---|---|
| Minimal executable unit | Well-typed |
| Execution locus | Well-typed |
| Resource basis | Well-typed |
| Transition model | Well-typed |
| Binding or realizing mechanism | Well-typed |
| Constraint surface | Well-typed |
Outcome:
Well-typed.
This does not mean the reform will reduce delay overall.
It means the claim has reached execution relevance.
Claim:
“A posted evacuation sign directs building occupants toward the nearest exit.”
Evaluation:
- Minimal executable unit: one occupant perceives one sign and changes route.
- Execution locus: occupant, sign, building layout.
- Resource basis: visible sign, lighting, occupant attention, perceptual access, physical path.
- Transition model: occupant perceives sign, interprets direction, changes route.
- Binding or realizing mechanism: sign convention, perception-action coupling, environmental placement.
- Constraint surface: visibility, language comprehension, lighting, accessibility, crowding, path availability.
Outcome:
Well-typed if the relevant actors can perceive and use the sign.
If the specified actors cannot perceive the sign and no accessible alternative exists, the claim becomes ill-typed for those actors.
The representation participates in execution only when embedded in a causal pathway.
Claim:
“The emergency procedure will work because all occupants will follow the written signs, including blind occupants who receive no accessible signal.”
Evaluation:
- Minimal executable unit: one blind occupant follows a written visual sign.
- Execution locus: occupant and sign.
- Resource basis: missing accessible perceptual channel.
- Transition model: visual perception is required but unavailable.
- Binding or realizing mechanism: absent for the specified actor.
- Constraint surface: perceptual constraint violated.
Outcome:
Ill-typed as specified.
The claim can be repaired by adding an accessible signaling mechanism, such as audio guidance, tactile signage, staff assistance, or another perception pathway.
Claim:
“There may be an unknown emergent practice that later helps communities coordinate more effectively.”
Evaluation:
The claim does not currently assert a specified execution pathway.
It points to a possible future discovery or emergence.
Outcome:
Outside current target domain.
If the practice later becomes identifiable and is proposed as execution-relevant, the filter can be applied.
The filter is analogous to a structural type check.
It does not determine whether an abstraction is true.
It determines whether the abstraction possesses the minimum structure required for executable contact with bounded reality.
A well-typed abstraction may fail.
An under-typed abstraction may later become executable.
An ill-typed abstraction cannot be instantiated without changing its defining assumptions.
An outside-domain abstraction may become evaluable later if it is brought into execution-relevant specification.
Executability is therefore a question of structural validity rather than outcome validity.
The filter should be judged by its ability to reject execution-irrelevant or under-specified claims early, not by its ability to describe complete or desirable systems.
This filter is not a theory of truth.
It is not a theory of success.
It is not a theory of persistence.
It is not a theory of governance.
It is not a theory of robustness.
It is not a theory of scale.
It is not a theory of all abstractions.
It is a minimal structural test for execution-aspiring abstractions.
Its purpose is to determine whether an abstraction possesses enough structure to cross from description into executable state transition within a bounded environment.
It is intentionally aggressive.
It is intentionally incomplete.
It is intentionally scoped to cases where explicit executable specification matters.
It is designed to reduce the candidate space of execution-aspiring claims by identifying which ones are execution-relevant at all.
Only after that question is answered do higher-order questions become analytically meaningful.