Etymology Is Not Decoration
The strongest case against this whole series is that I am dressing up a banal idea — "purpose generates implementation" — in Latin so that it sounds more serious than it is. I want to take that objection seriously enough to lose to it if it wins. So this article does two things: it lays out the etymology and the categorical structure that I think the Latin pair actually names, and then it gives the objection its full hearing and answers it honestly.
The Latin
Intentio is a noun formed from in- (toward) + tendere (to stretch, to tend). It names the act of stretching one's attention or one's effort toward something. In medieval scholastic usage, particularly Aquinas, intentio is the directedness of the mind at its object — what a later philosopher, Brentano, would re-import into modern philosophy as intentionality and what Husserl would build a phenomenology around — a debt I do not discharge here in a clause, but pay in full, on its own terms, in a companion piece: Intention et intentionnalité, which weighs exactly what this architecture borrows from Husserl's noesis/noema and what it must refuse.
Extensio is a noun formed from ex- (out from) + tendere (to stretch). It names the act of stretching out from a source, of being extended. In Aquinas it shows up in the discussion of quantity and dimension; in Spinoza it becomes one of the two attributes of substance (cogitatio and extensio, thought and extension); in Descartes it becomes the defining property of physical body.
The pair is not accidental. Both words share the root tendere. Both name a directionality of stretching. The prefix is the only difference: in- (inward, toward an object) versus ex- (outward, from a source). The pair encodes a single dynamic — stretching — from two perspectives:
- Intentio is stretching seen from the side of the stretcher (the mind tending toward).
- Extensio is stretching seen from the side of the stretched (the body stretched out from).
If you read these two words this way, the architectural move becomes obvious. An intention is a stretching-toward — a directionality of code (or of design, or of system) at an end. An extension is the stretched-out side of the same stretching — the artifacts that the intention has produced by being projected outward. Same dynamic, two perspectives. The two words pick out the two ends of one arrow.
The arrow itself is the thing. The two names are how you point at it from either end.
The categorical structure underneath
There is a way to make this more than literary, which is to read the pair through category theory. I want to be careful here: I am using categorical vocabulary as a clarifying language, not as a proof technique. The clarification is the point; the proof, if there is one, is not in this article.
Consider a category I whose objects are intentions. Now consider several other categories — T (types), C (classes), M (methods), Mod (modules), A (applications), TS (type-systems), R (requirements). Each of these categories contains the artifacts of a particular kind.
What I want to claim — and this is the move that makes the etymology earn its keep — is that there is a family of functors from I to each of those target categories:
Ext_T : I -> T
Ext_C : I -> C
Ext_M : I -> M
...
Ext_R : I -> REach functor is an extension kind. Each functor takes an intention and produces an artifact (or a set of artifacts) of that kind. The functoriality matters: if an intention has a refinement relation to another intention (a morphism in I), each Ext_X produces a corresponding refinement in the target category (a morphism in T, C, etc.).
The existing @frenchexdev/requirements-* kernel is, in this reading, the implementation of the single functor Ext_R. It is the verifiable-contract projection. The reason the kernel works is that this functor is well-defined. The reason the kernel feels incomplete is that there are other functors in the family which are also well-defined and which the kernel does not name.
This is a stronger claim than "purpose generates implementation." It is the claim that the generating relation is structured — it has the same shape across all extension kinds — and that the structure is what should be reified, not any particular projection.
A diagram, plain mermaid
The diagram has three rows of arrows. The horizontal arrows out of Intention are the projection functors — they go to the various extension kinds. The vertical arrows (parent and child intentions) are morphisms inside $\mathcal{I}$, the intention category itself, which the projection functors preserve.
The diagram looks decorative. It is the smallest non-trivial picture of the hypothesis. If the picture is wrong, the series is over.
The counter-argument I have to answer
The objection I want to engage at length is that this whole apparatus is rhetorical, not architectural. The objection says: you have invoked Aquinas, Spinoza, Husserl, and category theory in five paragraphs, and underneath all of it you have proposed nothing that "the code has a purpose and the purpose generates the code" does not already say in plainer English. The Latin and the functors are intimidation, not content. They make the reader less likely to push back, not more likely to understand.
There are three things I want to say in honest response.
First, the partial concession. The objection is partially right. The categorical phrasing in particular is doing more work than I can cash out in this series. I am not going to prove that the family $\text{Ext}_X$ are real functors in any rigorous sense. I am not going to verify functoriality (that refinements in $\mathcal{I}$ map to refinements in target categories) for more than two of the projections. The category theory is a picture of the structure I think is there, not a derivation of it. Calling it functors and writing it in LaTeX is a small piece of intimidation and I am admitting that.
Second, the defence of generative metaphor. The Latin etymology, however, is doing different work — work I will defend. I am claiming the pair intentio/extensio is a generative metaphor in the sense Lakoff and Johnson use the term: a metaphor that produces new structure rather than merely dressing up old structure. The test of a generative metaphor is whether it lets you see relations you did not see before. The relation I claim it lets you see is the symmetry: that the arrow has two ends, that the upstream end (intention) and the downstream end (extension) are the same dynamic seen from opposite sides, and that this symmetry has API consequences (the bidirectional pointer question raised in Part 1). The English phrase "purpose generates implementation" does not surface that symmetry. It treats "purpose" as one thing and "implementation" as another thing and leaves the directionality implicit. The Latin pair makes the directionality the content.
Third, the falsifiability. I owe the reader a way to tell whether the generative metaphor is actually generating anything or whether it is decorative. The test I propose is concrete: in Parts 5 through 8, I will sketch four extension-kind APIs (TypeExtension, MethodExtension, ModuleExtension, TypeSystemExtension). If those APIs all turn out to require the same kernel shape — a projects-from(Intention) pointer, a kind tag, a refinement-preserves law — then the symmetry the metaphor surfaced is doing real architectural work. If the APIs do not converge on a shared kernel shape, the metaphor was decorative. The reader can keep track and call it.
I think this is the honest position. The etymology is doing real work but not all the work it pretends to do, and I am marking which is which.
What this article does not settle
It does not settle whether the categorical structure exists in any rigorous sense. It does not settle whether the symmetry produces API consequences in every extension kind or only some. It does not settle whether "Intention" is a noun (an object in some Intentions registry) or a relation (a directionality of code, with no separate object). It does not settle whether the parent-child morphisms inside $\mathcal{I}$ are the same as @Refines in the existing kernel.
Part 3 is the part where I look around at what we already build, and notice that several extension kinds already exist in everyday TypeScript — we just do not call them that. The inventory is meant to make the hypothesis concrete enough that the abstract apparatus of this article either earns its keep or collapses.