Component realization

A deployable component, end to end

Take a concrete thing: a small service someone wants to run. Follow it from a static declaration to a running effect, and two questions separate out that the settled substrate does not answer on its own.

The first is capability: what does this component afford others, and what does it require to run? Not its shape — horos already judges whether a value has a given form (v : T, wf(T)). Not its permissions — thesmos already judges whether an actor may act. Capability is the integration surface in between: that an entity provides an operation, requires a cell, emits on a wire, or needs authority to read a secret. It is sketched with judgments like provides(Entity, C), requires(Entity, C), and operation(C, Op, InputType, OutputType, Effect) — referencing horos for the type slots and thesmos for the authority patterns, replacing neither.

The second is realization: how does an immutable declaration become an effectful, running thing? arche's runtime-host RFC names the skeleton, which the browser app-shell and the service runner each grew independently:

declaration → immutable artifact → desired state → runtime effect → observation

Read against a real component:

• declaration — facts describing the component: what it provides, requires, and wants to run.
• immutable artifact — the bundle's bytes in CAS, addressed by hash, bound into a space by a fact. Necessary but passive: bytes plus facts only say "these bytes exist."
• desired state — a fact asserting the service should run (arche's runner reconciles against a service.desired fact pointing at an immutable manifest).
• runtime effect — a provider makes it true; nothing in the theory runs anything itself.
• observation — the effect described back as new facts (service.started, …stopped, …failed).

Realization defines the checkable claims around running — manifest(M), host_supports(Host, K, Profile), realizable(Host, M), deployment_plan(P, Desired, Host, M), realizes(Observation, Desired, Host, M) — and stops there. The runner stays a fact-driven occupant, not a primitive; the instantiation semantics may be constitutional even though the implementation is not.

Capability vs realization — the type and the term

The working split is dynamis vs energeia: capability is the abstract affordance (what a thing can do), realization is the instantiation witness (potential brought into effect). They look adjacent — provides(Entity, C) against manifest_provides(M, C) — which is exactly the seam being pressure-tested.

Note also that "artifact" is not its own theory here. CAS is the byte mechanism; an artifact is the immutable, fact-mediated object the realization theory reasons over, with build and deployment plans folded in. The irreducible thing a running component adds over a formed value is not its shape and not its bytes — it is behavior brought into effect.

These are candidates, not settled

Capability and realization are recorded as candidate theories, not adopted ones. The settled base is two: authority (thesmos) and form (horos). No repos exist for capability or realization; the names (dynamis, energeia) are placeholders, minted only on crystallization. Read this walkthrough as the strongest current hypothesis for how a component reaches a running state — see the decisions for where the line is drawn, and where it stays open.