Whitepaper / Network and Trust

Identity and Provenance

In the proposed design, a Capability keeps one service identity across products, apps, and integrations. Provenance ties that identity to the Creator, the version and claim that governed a purchase, and the execution, verification, and settlement records that purchase produced. Ghast Protocol is in development, so none of this can be resolved on a network today. The point of writing it down is so later chapters can talk about history, distribution, and financing without mixing one service into another.

These links preserve attribution while the underlying workflow remains Creator-controlled. The Privacy Model defines the associated disclosure boundary. Identity is not a copy of the method. Provenance records who offered which version of which claim, and which records belong to that offer. It does not publish the prompts or the tool sequence.

Service-level identity

One underlying agent or workflow can support multiple Capabilities, each with its own claim, commercial terms, evidence requirements, and Capability History. Identity and performance therefore remain attributable to the individual service rather than the underlying system or Creator as a whole.

That split is easy to lose if “the Creator’s reputation” becomes the unit. A Creator might offer a narrow document summary and a separate code repair. A failure of one claim would be a fact about that Capability. It would not, by itself, be a fact about the other Capability or about every future workflow in the Creator’s Workbench. Reputation and Delivery History builds the record at the service level for this reason. Capability Definition is the unit being identified.

Service-level identity is also what Distribution and Integration needs. An agent, an application, and an API would be different doors to the same Capability. If each door invented its own name, a buyer could not tell whether the history on one door applied to the other. The design keeps one canonical identity so the doors do not become different services by accident.

Workbench itself is not a Capability identity. Chat, Coding, and Agent Team are experiences inside the live product. A Team teammate with a name and a memory is not a Protocol identity. Ghast Agent Team describes that operating model. Moving from a teammate to a Capability would be a packaging decision under Protocol, which is not live. The same person can have a Workbench account and, in the design, later be the Creator of several Capabilities. The account and the service identities are not the same object.

Versioned provenance

A Capability’s claim, price, inputs, execution conditions, or evidence rules may change. Each purchase remains bound to the version selected by the Buyer. Later revisions apply only to later purchases.

This is the practical content of provenance. A buyer who paid against a claim that named two tests is still owed those two tests after the Creator drafts a third. The new version can exist. It does not rewrite the open purchase. Capability Lifecycle settles the purchase that was made. Governance and Upgrades says the same thing for protocol rules: a purchase stays on the rules in effect when it was made. Versioned provenance is the service-level half of that non-retroactivity. Governance is the system-level half. They are specified separately so a claim edit is not mistaken for a protocol upgrade, and a protocol upgrade is not mistaken for a silent change to someone’s claim.

A provenance record binds the Capability and version, the Creator, the governing Defined Claim, the evidence requirements, the Execution Record, the Verification Result, and the completed Settlement Record. Drop any one of those and the later reader cannot reconstruct what was promised, what ran, or how it resolved. Actors and Core Objects names those records from the point of view of the parties. This chapter names them from the point of view of the link between them.

The Challenge path uses the same binding. A dispute is about a particular execution under a particular claim, not about the Creator in the abstract. The public Challenge Window can show the execution identifier, the version, and the deadline, as the Privacy Model allows, without replacing the version the buyer purchased. Challenges and Disputes is the procedure. Provenance is why the procedure has a stable object to point at.

What identity is not

Identity in this chapter is not a social profile, not a hackathon ranking, and not a token balance. Recognition and Traction records a hackathon result. That fact is about the project. It is not a Capability identity, and they do not transfer a delivery history that Protocol has not produced.

Identity is also not $GHAST. The proposed token functions in $GHAST Utility attach bonds and burn reserves to a Capability and to an execution. They do not replace the service identity. A bond without a versioned claim would be a pool of value with nothing to judge. The design keeps the identity on the service and the economic commitment pointed at that service. No such commitment is live.

Provenance does not guarantee that the Creator’s runtime was safe. Security and Risk keeps runtime compromise, custody failure, and financing loss outside the meaning of a narrow verification. A complete provenance record can still sit beside an unresolved infrastructure risk. The record makes the commercial facts attributable. It does not make every technical risk disappear.

How to read a future listing

If Protocol were live, a buyer would start with the canonical identity and the version, then the claim and the evidence rules, then the history that actually belongs to that version’s line of executions. A listing that offered “the Creator’s agent” without a version would be a different product from the one this whitepaper specifies. Capability Examples keeps each example inside a bounded outcome so that the identity stays small enough to verify. Use those examples as shapes, not as live services. Use the Glossary for the canonical words. Use the website glossary only as the shorter product map.