Whitepaper / Network and Trust

Reputation and Delivery History

Trust, in this design, belongs to a specific Capability, not to an account and not to the person behind it. The history would record what ran, which version and claim governed the purchase, how delivery was judged, and how the transaction resolved. Ghast Protocol is in development, so there is no history to query. This chapter specifies the record a live protocol would keep, and the summaries that would mislead a buyer. It is not a score for Ghast Workbench, and it is not the hackathon result in Recognition and Traction.

Two service-level histories

Capability History records every execution, every provisional Verification Result, and every final resolution. Verified Delivery History contains only protocol-final claim-met outcomes.

The split is the chapter. A buyer doing diligence needs the failures, the refunds, and the disputes, not only the successes. A financing test that asked only for successes would still need to know they were protocol-final and that the claim was met, which is why the second record is narrower rather than friendlier. Capability Financing may use verified history and recurring revenue as inputs. It does not get to replace the full history with a highlight reel. Capability Economy is the chapter that places both records inside a proposed market. The website explainer of the Capability Economy is a shorter status page. This chapter is the record itself.

Every execution contributes to Capability History, including ones that fail the claim, ones that are cancelled, and ones that end indeterminate. A final claim-met delivery would also enter Verified Delivery History and, in the utility design, is the case that burns the reserved $GHAST. A breach, a cancellation, or an indeterminate result would not. $GHAST Utility states that rule. This chapter states what the history contains either way. Burn is not live, and neither record is being written.

What a history must be able to answer

A useful entry answers the questions System Overview raises and then refuses to collapse. What ran? Which Capability version? Which Defined Claim? What evidence was required? What did verification conclude, and was that conclusion provisional or final? Did a Challenge open inside the three-day window? How did settlement resolve payment and any bond? Capability Lifecycle is the order of those events. Challenges and Disputes is the dispute branch. History is the log after the branch closes, plus the provisional states that were visible while it was open.

Claim context belongs in the full history because a result without the promise is not interpretable. “Verified” means the evidence met that claim, as Evidence and Verification and Security and Risk both limit it. A history entry that drops the claim text, or that mixes versions, would let a narrow success advertise a broader service. Identity and Provenance is what keeps the version on the entry.

Payments and revenue events sit in Capability History so a later reader can see money and delivery together. They do not sit there as a price list for $GHAST. Buyer payment is for the work. Proposed token functions are separate. Payments and Fees holds that line. A revenue event in a design document is not revenue a reader can earn.

Reputation summaries

Interfaces that summarize Capability History would identify the supporting evidence scope, the Capability versions, the time window, and the calculation basis. A badge that says only “reliable” fails this rule. The reader must be able to see which versions were included, which dates, and how the figure was computed. Otherwise two channels can show two reputations for one service and call them the same history. Distribution and Integration requires one history across agents, applications, and APIs. The summary rule is how that requirement survives a short label.

Reputation and financing summaries would separate independent demand from Creator-controlled, related-party, circular, or refunded activity, and they would use net settled revenue rather than volume alone. A Creator who buys their own Capability, or who routes purchases in a circle, can inflate a count of executions. Refunded payments are not net revenue. The design treats those as filters on the summary, not as a claim that the filters are perfect. Security and Risk says sybil identities and collusion can still distort observed demand. This chapter requires the summary to show its basis. It does not promise that every manipulation will be caught.

Provisional verification is not reputation. A result inside the Challenge Window is still open. Counting it as a verified delivery would publish a success that settlement might reverse. Verified Delivery History waits for protocol-final claim-met outcomes for that reason. Interfaces may show the open state. They may not quietly promote it.

What this record is not

Workbench usage is not Capability History. A Chat reply, a merged coding change, or an accepted Team work item can be useful and still be outside this record. There is no Defined Claim, no Protocol verification, and no settlement. Persistent Memory and Activity Recorder are product features with their own controls. They are not delivery evidence for a Capability.

A star rating on an account, a follower count, or a hackathon place answers a different question. They can be true and still say nothing about whether a named service met a named claim on a named version. The glossary on the website is a short product map. The whitepaper glossary holds the canonical definitions of Capability History and Verified Delivery History used here. When the words diverge, this book’s glossary is the one the protocol chapters mean. Neither glossary creates a live history.