The words we use.

Plain definitions for the ten product terms used across Hyperscale pages, contracts, generated tools, and agent references.

Arc Ledger. The seven ways money can move inside a checked Product. Brick. One reusable money flow, such as a held payment or split. Instrument. A business record with its states and allowed actions. Action. A checked call that a person, application, or agent can make. Action caller. The party that fires an action: a tenant, operator, or machine. Blueprint. A ready-made financial Product design that can be adapted. Product. The checked sandbox build created from a design. Estate. One complete hosted test installation of Hyperscale, including its API, portal, database, and ledger services. Trust file. The evidence attached to a business record for later review, such as inspection, authentication, delivery, or proof-of-work records. Public actions. The canonical action ids frozen into a Product. Older dossiers called this field publicIntents.

Hyperscale is the governed runtime where founders and agents build and operate financial products through the same contract. A founder can work in the portal with the Architect. Developers can use the CLI, Product API, generated SDKs, or MCP. All of those paths expose the same Product instruments and actions. Every state change records who asked, what ran, and the result in a receipt. Hyperscale is not a bank and never holds a tenant's money under its own name.

Every Product starts in a sandbox with test identities, provider simulators, and play money. No tenant is live today. The current systems connect to no real bank infrastructure. Moving a future Product to live use requires a separate Product Activation review, identity checks, provider approval, and billing readiness. A partner financial institution would perform each regulated money movement.