In systems where AI deeply participates in development, the first-principles question is not "how to constrain AI's behavior," but "what long-term structure the system should converge to."
Only after this direction is clearly defined can mechanisms like harness, guardrail, verification, audit, and closure truly have meaning. Otherwise, they are merely efficiently solidifying a wrong baseline.
This claim is inevitable because AI collaboration pushes "trajectory convergence"—a problem long treated as an add-on in software engineering methodology—to a position where it must be explicitly modeled.
1. Why Harness Is the First Thing People Think of When Discussing AI Engineering
In current discussions about AI-assisted development, the most common terms are:
guardrailverificationreviewfeedback loopagent harness
This set of intuitions assumes a single premise by default:
The correct direction of the system is already known.
Given that premise, the problems naturally become:
- How to limit deviations
- How to expose failures as early as possible
- How to make reviews stricter
- How to prevent agents from going rogue
This language suffices for small tasks. For a script, a CRUD page, or a local bug fix, you usually already know "what a correct result looks like"; the remaining work is mainly about execution and verification.
But what truly makes large systems difficult is often not "how to prevent crossing the line," but "which path is the right long-term structure in the first place."
To answer this question, we must first recognize one thing: all current harness-type mechanisms rest on an implicit premise—the evaluation unit is primarily state, and trajectory convergence relies on the developer's tacit sense of direction as a backstop. AI collaboration removes precisely this backstop.
2. The Backstop That Has Been Removed
Open any mainstream engineering methodology—TDD, DDD, Clean Architecture, Agile, Code Review culture—and their first-class evaluation targets are almost always state:
- Evaluate "whether this PR is correct," not "whether the cumulative direction of the last 100 PRs is correct."
- Evaluate "whether the current architecture is clean," not "whether the architecture is being continuously pushed toward a stable form during evolution."
- Evaluate "whether tests cover the current behavior," not "whether the test suite itself has been corroded by implementation details."
Traditional methodologies are not entirely without trajectory awareness—refactoring, technical debt, code smells, evolutionary architecture, and Lehman's laws of software evolution all touch on trajectory. But these concepts exist in the methodology as corrective mechanisms and diagnostic vocabulary, not as fundamental objects. When a theory must continuously introduce negative concepts like "debt," "fragility," and "corrosion" to retroactively acknowledge trajectory problems, it reveals that its foundational category set lacks a positive trajectory object.
This state-centric paradigm has worked for so long because human engineers themselves act as a perturbation source with low frequency and stable directional sense. A person writes a few hundred lines of code per day; each perturbation is small in magnitude, and a continuous sense of direction is maintained in the mind. State-level quality assurance combined with the programmer's implicit directional sense ensures that the trajectory does not drift.
AI collaboration removes this backstop. AI is not a faster programmer; it is a structurally different perturbation source:
- High frequency: A single session can generate hundreds of lines of code spanning multiple modules in minutes.
- High magnitude: Each generation can introduce cross-boundary structural changes.
- No persistent directional sense: Each session is independent, with no implicit architectural judgment carried across sessions.
- Highly reasonable locally: Interfaces, types, tests, and documentation can be produced simultaneously, and each piece passes inspection when viewed in isolation.
The last point is crucial. In AI collaboration, all state-level checks can pass while the system as a whole drifts continuously.
Plan 76 of nop-chaos-flux is a typical example. An attempt to remove the local state mirror in array-editor / key-value immediately caused 11 test failures. But what was exposed was not a specific bug, but a deeper fact: the tests themselves had become tightly coupled to the timing of the old implementation. From a state perspective, every incremental change had passed review and CI; from a trajectory perspective, the test suite had unconsciously drifted into a position where it could no longer support structural evolution.
Traditional theory has a symptom name for this—"test fragility"—but a symptom name is a cross-sectional diagnosis. It does not name the process by which 100 legitimate commits accumulate into fragility. Trajectory problems are process problems, and process problems require a process language.
Thus, the issue is not that AI makes old problems worse, but that AI pushes trajectory problems from an occasional repair target to a high-frequency, first-class citizen. For these problems to enter the methodology's field of view, engineering methodology must adopt "trajectory" as a fundamental category.
3. Dynamical Systems Language: Making Trajectory Problems Explicit
In mathematics and physics, a dynamical system refers to a system whose state evolves continuously over time, with each next state depending on the current state. What we care about is not just whether it is correct at a single moment, but what kind of trajectory it traces out over time.
Translated to large-scale AI development, this language corresponds to four mutually defining fundamental objects:
- State Space: All possible implementation states the system can evolve into under current constraints.
- Attractor: The stable structure to which the system is repeatedly pulled back during long-term evolution.
- Trajectory: The actual evolutionary path left behind after each round of generation, verification, and correction.
- Control: The various mechanisms that continuously influence the trajectory through local signals.
The repository, under existing constraints, has a set of all possible combinations of code, documentation, and tests it could evolve into—this constitutes the state space. The continuous actions of humans, AI, review, CI, and documentation updates constitute the evolution rules. The interaction of these two forms the live repo history, which is the trajectory. The attractor is the stable structure to which the system is repeatedly pulled back during long-term iteration.
One point must be made clear: this language is not a "more elegant way of saying things," but the foundational language of a new ontology. The four concepts—state space, attractor, trajectory, control—define one another; if one is missing, the other three cannot be rigorously expressed. Attempting to translate these concepts into the language of the old ontology (architecture, constraints, goals, process) inevitably incurs information loss—this is the root of misreadings like "Isn't Attractor Guided Engineering just Harness?"
The relationship among the four objects is:
State Space → Attractor → Trajectory → Control
This is not a rhetorical ordering; it is a logical dependency. Without defining the state space, there is no talk of an attractor; without defining the attractor, one cannot judge whether the trajectory is drifting; without trajectory judgment, control has no target.
The "before" here refers to logical priority: in execution, attractor and harness co-evolve in a closed loop, but the attractor can be conceptually defined independently of the harness, while the harness cannot be conceptually defined independently of the attractor (to correct deviation, toward what?). This asymmetry corresponds to the relationship between final cause and efficient cause in dynamical systems—acknowledging co-evolution does not weaken the "before" claim. Final cause and efficient cause act together in physical systems as well, but the final cause remains the logical prerequisite for the efficient cause.
4. What Exactly Is an Attractor
Take the well-known Lorenz attractor as an example. It is implicitly defined by differential equations. It is not a checklist that enumerates all correct trajectories in advance, nor is it a simple boundary. Within the attractor, local trajectories are highly complex and appear nearly chaotic in the short term, yet the whole does not fly apart randomly; it is always pulled back into the same type of geometric shape.
Lorenz attractor: Local trajectories are highly complex, yet the whole is still constrained by a stable structure. Chaos does not equal randomness; local unpredictability does not mean the whole is out of control.
An engineering attractor works the same way. It is more like an "equation-defined manifold" than "a list of all legal points enumerated one by one." The equation does not write out every point on the manifold in advance; it only stipulates which relations must hold. Points satisfying these relations naturally fall within the same structure.
Key difference from traditional architecture concepts: DDD and Clean Architecture also emphasize long-term structure, but they treat that long-term structure as a target state—the methodology's job is to "reach X." A trajectory ontology treats the long-term structure as an attractor—the methodology's job is to "return to the vicinity of X no matter how far you are pushed away." The second perspective addresses stability under perturbation. This is exactly the core problem in AI collaboration scenarios, and exactly the problem for which traditional methodologies lack first-class conceptual tools.
To prevent conceptual drift, an attractor in engineering can be strictly divided into three layers:
- Structural layer (the attractor itself): A small number of high-order invariants, such as how responsibilities are divided, how boundaries are established, and which structural relationships cannot be violated.
- Carrier layer (the engineering carrier of the attractor): Externalizing these invariants into versionable, auditable documents.
- Implementation layer (the instantaneous projection of the attractor): The parts of the current code that actually embody these invariants.
The attractor is not the document; the document is the carrier of the attractor. The attractor is not the code; the code is an instantaneous projection of the attractor.
This layering is important because it resolves a common confusion: "When architecture docs and code conflict, which one do we follow?" The answer is not "which one is more authoritative," but "what question are you asking?" If you are asking about current implementation behavior, the code is authoritative. If you are asking where the system should converge, the docs are authoritative. If you are asking why a certain path was abandoned, logs/bugs/analysis are authoritative. Each layer is authoritative only for its corresponding question.
5. The Repository Begins to Bear the System's Truth, Making Harness Infrastructure
Once AI deeply participates, the repository is no longer merely an external projection of human cognition; it begins to become the sole carrier of the system's truth. No one person fully grasps all the design details in the system, and no one can answer questions about the system's design without consulting the project source code. What the next session can re-read is not the full intent in the author's mind, but the code, diffs, logs, tests, and documentation.
This has a direct engineering consequence:
Generation and acceptance must be genuinely separated.
Generation actions can be completed at high speed by AI within the same context, but acceptance can no longer rely on that generative context itself. You must return to the external evidence in the repository and re-evaluate:
- Whether the behavior was truly implemented.
- What the current baseline actually is.
- Which materials are authoritative.
- Whether this "completion" is just a feeling of completion.
It is precisely because the repository begins to bear the system's truth that generation and evaluation must be separated; and it is precisely because generation and evaluation are separated that the harness is upgraded from a "safer engineering habit" to necessary infrastructure.
In traditional collaboration, harness is optional discipline; in AI collaboration, harness is the necessary condition for making trajectory judgment possible. The reason is this: while AI generates code, it also generates all the materials for judging whether that code is correct—types, tests, documentation, completion summaries are all produced together by the same context based on the same understanding. If that understanding is skewed, all "verification evidence" will be skewed consistently in the same direction, not contradicting each other, yet entirely wrong as a whole. This self-verification trap is naturally weakened in human collaboration—CI rules, reviewers, spec documents are all independent external standards maintained by different cognitive subjects. AI collaboration breaks this independence, so we must use engineering means—fresh sessions, independent audits, returning to live repo forensics—to artificially reconstruct the separation of generation and acceptance.
Under repo-truth conditions:
-
test / lint / auditfunctions more like measurement. -
owner doc / plan / closurefunctions more like constraints. -
logs / bugs / discussionsfunctions more like trajectory records and externalized memory.
6. Three Most Common Ontological Confusions
First, mistaking the attractor for a boundary.
Boundaries answer "what cannot be done," and violating them causes an error immediately. Attractors answer "where the system should converge in the long run." A single violation may not cause an error, but persistent deviation causes structural decay. Boundaries define forbidden zones; attractors define stability zones. Confusing the two downgrades the attractor to a stricter guardrail, missing its core capability of handling "stability under perturbation."
Second, mistaking the attractor for a stronger guardrail.
Guardrails operate at the execution layer (checked for each action), while attractors operate at the direction layer (whether the accumulation of multiple actions trends toward it). Understanding it as stricter governance, denser constraints, or stronger auditing still reduces the primary problem to the control layer. The root of this reduction is the failure to recognize that the two belong to different levels.
Third, mistaking the attractor for another way of saying "control target."
The phrase control target seems very close, but it assumes that a control framework is already in place. Under a trajectory ontology, the attractor's role is to provide the final cause for control—it is prior to control, not within it. If the attractor is not defined first, so-called control has no target, and mechanisms like harness, guardrail, verification, and audit have no unified meaning.
7. In the nop-chaos-flux Repository, the Attractor Is First and Foremost docs/architecture/
If the attractor remains only at an abstract level, it has no real engineering significance. For nop-chaos-flux, what first bears the attractor is the owner-doc system with precedence within docs/architecture/.
In this repository, the engineering landing point is clear: the specification definitions under docs/architecture/ come first, followed by convergence mechanisms like plan, verification, audit, and logs.
Within docs/architecture/, this "equation layer" also has a clear precedence:
-
docs/architecture/README.mdis responsible for explaining the architecture hierarchy and reading order. -
flux-design-principles.mdhandles the direction layer, explaining design intent and stable principles. -
frontend-programming-model.mdhandles the top-level specification layer, defining primitive identity, macro boundaries, and hard invariants. -
flux-core.mdhandles the current codebase-wide baseline. - Narrower architecture docs define local contracts within their respective topics.
In nop-chaos-flux, the structural layer of the attractor is not an abstract "correct architecture," but is defined by a small number of high-value invariants: the closed set of seven primitives, the compile-first pipeline, the Template/Instance separation, Data/Capability orthogonality, the unified renderer/hook contract, and the dependency direction flux-core → flux-formula → flux-compiler → flux-action-core → flux-runtime → flux-react.
These are not parallel pieces of governance material; they are structural equations fixed by owner docs. The value of architecture lies not in describing everything, but in making wrong structures unable to continue existing legitimately.
It is precisely for this reason that many truly important convergence actions in this repository end up manifesting as "a certain old structure being excluded from the legitimate state space."
The final removal of CompiledSchemaNode is a typical example. It was not merely a refactoring cleanup; it demonstrated that once the new baseline of template/instance separation was established, the old intermediate structure, though still functional, no longer belonged to the correct structure and was thus excluded.
Similarly, the three-way split of flux-compiler / flux-action-core / flux-runtime is not simply a matter of "extracting two more packages," but a case where the attractor became more precise: the system was not just "able to run," but was further converged into a more stable responsibility structure.
8. What Is Harness
If the attractor solves "what is the direction," then harness solves:
How to continuously measure, correct, and update the system's trajectory through local signals.
The term "harness" here does not mean the narrow testing harness, but a broader execution scaffold. It typically includes: context routing, separation of implementation and acceptance, planning and closure conditions, verification mechanisms, audit mechanisms, diagnostic tools, and externalized memory.
In this repository, at least five layers of harness can be seen:
1. Routing Harness
docs/index.md and docs/architecture/README.md determine: what to read first for a given problem, what is the current baseline, and what is merely analysis, plan, or history.
2. Plan Harness
docs/plans/ addresses "how this round of expansion closes," not "what the system is."
Fields like current baseline, goals / non-goals, exit criteria, validation checklist, and closure audit evidence define how a local trajectory can be effectively closed.
After Plan 145's closure/audit, the newly confirmed follow-ups were broken out into Plan 146. Plan 143's closure assumptions were repeatedly overturned by fresh audits until the live repo truly crossed the line and closure was allowed. Plans here are not a to-do list, but a local convergence mechanism—they don't just list "what needs to be done now," but stipulate where this round of expansion must close, what exit criteria must be met, and what independent evidence closure requires.
3. Verification Harness
lint, check, typecheck, build, test push high-frequency, clear, automatable deviation detection to the machine layer ahead of time.
4. Audit Harness
Not all deviations can be caught by automated rules. Higher-level semantic drift, structural bias, false completion, and problems that are locally self-consistent but globally distorted still require independent auditing.
Auditing itself is also a closed loop: discover deviation points, filter out conflicts and false problems, and return to the live repo for confirmation. The focus of high-quality auditing is not to pile up more problems, but to eliminate invalid problems as quickly as possible.
In this repository, one of the most critical harness rules is: never let the same context serve as both implementer and completion judge. Completion must be re-evaluated against the live repo by a fresh session or independent audit. The reason the closures of Plan 143 and Plan 145 carry weight is precisely because "completion" is not self-reported by the implementer, but comes from an independent convergence judgment.
5. Memory Harness
docs/logs/, docs/bugs/, docs/discussions/ constitute cross-session externalized memory.
This layer is especially important because for AI, "why that understanding is invalid" is itself part of the system's memory. It is often insufficient to retain only the final conclusion; you must also retain:
- Which premise has been falsified
- Which path has been proven to diverge
- Which terminological translation degrades the problem
- Which "completed" judgment was later overturned by the live repo
Without this memory harness, the system loses a portion of its historical trajectory information each time.
True closed-loop is not "define the attractor once, then execute harness forever," but "define attractor → expand → correct → update attractor → expand again." The three-way split of flux-compiler / flux-action-core / flux-runtime is an example of the attractor being refined by practice before continuing expansion.
9. Why a New Attractor Is Usually Not Evolved by AI on Its Own
Even with harness in place, you cannot expect AI to slowly evolve a new attractor on its own through high-speed iteration.
At least under the training distribution and biases of current mainstream models, this generally cannot be expected to happen naturally.
To be more specific:
- Current mainstream AI excels at high-speed expansion and convergence around an existing attractor.
- However, it typically falls back to the average solution it has seen.
- Truly novel conceptual decompositions, boundary redefinitions, and architectural languages still require a human to propose first.
The responsibility for defining a new attractor cannot be silently outsourced to AI.
In large-scale framework development, the division of labor between humans and AI cannot be simplified to "AI writes code, humans do review." The more realistic division is:
- Humans define new attractors.
- AI performs high-speed expansion around the defined attractor.
- Harness continuously pulls the trajectory back on track.
Concepts like the separation of ActionScope and Data Scope, or lexical scoping—concepts that genuinely change the system's structural language—cannot grow by letting AI freely sample average solutions. They are new attractors that must be proposed first; only then can AI perform large-scale expansion on the new baseline.
A limitation must be acknowledged: this means the effectiveness of this methodology depends on the presence of people within the team capable of defining attractors. This is not a weakness of the methodology, but a fact it correctly identifies—architectural judgment is a scarce resource. In traditional collaboration, this judgment could partially reside in the architect's mind, transmitted through oral tradition and code review. AI has no cross-session memory; any architectural judgment not explicitly externalized does not exist for AI. The engineering contribution of this methodology is precisely to externalize this scarce resource into a versionable, auditable, inheritable repository structure so that it does not have to leave with the individual. However, if no one on the team can make such judgments at all, the methodology cannot generate them out of thin air.
10. Conclusion
The truly difficult part of large-scale AI development is not getting AI to write more code, but ensuring the system continues to converge toward the correct structure during high-speed expansion.
This convergence problem has no positive object in traditional methodologies where state is the first-class citizen—it can only be indirectly acknowledged through negative terms like "debt," "fragility," and "corrosion." For the convergence problem to become a first-class citizen object that can be expressed, discussed, and engineered, the methodology must incorporate trajectory into its foundational categories.
Whoever proposes a new attractor defines the structural baseline for the system's subsequent evolution.
Compressing this methodology to its core, only one line remains:
State Space → Attractor → Trajectory → Control.
This is not a more complex engineering process; it is a more fundamental engineering conceptual structure. Only with a structure defining where the system should converge in the long run can there be a judgment of whether the trajectory has deviated; only with a judgment of trajectory deviation can the subsequent harness, guardrail, verification, audit, and closure have a unified meaning.
In the age of AI, what is truly scarce is not more agents that can write code, but people who can first answer the question, "Where should the system converge?"
nop-chaos-flux is open source:
Top comments (0)