Capability Runtime: make Reality addressable before enrollment
The account-first Internet waits for someone to register and upload what they own. HSIMC starts from Reality that already exists, structures its capabilities and gives those capabilities stable Runtime addresses.
Reality exists before an account
A building, station, machine, material, organization, website, process or service does not begin to exist when someone creates a platform account. HSIMC can observe and structure that Reality first, then make candidate capability addressable while ownership, current availability and Authority remain explicitly unresolved.
Runtime is not an API key
Runtime ID
A stable addressable identity for a bounded Reality/Capability context.
Authority Grant
Who may do what with the Runtime, under which scope and Context.
Credential / CAK
A revocable proof used to exercise a particular Authority. Credentials can rotate without changing Runtime identity.
Capability
The value the Runtime can expose or participate in when its evidence, Context and Authority permit.
N:N:N Reality
One physical asset can support many Runtimes under different scopes. One Runtime can compose many machines, materials, people, services and software resources. One Capability can be exposed by many Runtimes across many organizations and places.
This is why HSIMC does not model global capability as “one account owns one listing.” The useful graph is:
Want this capability to empower what you can do?
Add your Runtime. HSIMC can then compute the Minimum Authorized Path by which a visible Capability may become accessible inside your Runtime's Intent and Context. When accessible capability is composed, executed, evidenced and accepted, the new composite Capability can itself become addressable as the next Runtime.
This is Authorized Capability Resonance: Capability Inventory can grow through use rather than waiting for account enrollment.