System Overview
Ghast AI connects private AI work in the Workbench with service-level commerce in the Protocol. The Capability is the market primitive that carries a defined service between them. This chapter follows one piece of work along that path, using the software security review from Capability Examples. Ghast Protocol is in development, so the steps after Workbench describe the protocol design.
1. The work starts in Workbench
Work begins in the Workbench. A security engineer builds a review workflow in Ghast Workbench as an Agent Team. One agent runs static analysis, another checks dependencies, a third validates findings, and a lead agent assembles the report. The playbooks, prompts, model configuration and prioritization rules live in that workspace. The engineer runs the workflow on internal repositories for months, adjusting it until its reports are consistently useful.
Nothing in this step is a sale. The engineer is the only judge of the output, and the method is never exposed. Ghast Workbench and Ghast Agent Team describe this layer.
2. One service becomes a Capability
A Creator packages one specific service as a Capability with a Defined Claim, price, and evidence requirements. The engineer does not publish the whole workflow. They choose one bounded service and write it down:
Review the identified commit within the listed directories and deliver a report by the agreed deadline. Each reported issue must include severity, affected location, evidence, and a reproducible explanation.
The evidence requirements name what will show delivery: the repository revision and scope, input and output manifests, findings mapped to file locations, the required report fields and a delivery timestamp. Those are things a buyer can check. The playbook that produced the findings is not on the list. Defined Claims explains how a claim is made narrow enough to test.
3. A Buyer purchases a fixed version
A Buyer purchases a fixed version and supplies the required inputs, while the Creator-controlled workflow performs the work. Here, the buyer pays in fiat or an approved stablecoin and supplies a commit hash and a list of directories. The purchase binds the claim, price, evidence rules and transaction terms of that version. If the Creator later adds a requirement, such as a fix suggestion for every finding, that change applies to later purchases, not to this one. Identity and Provenance explains this version binding.
The buyer’s code is an input to this job, not part of any public listing. The Privacy Model limits who can see it.
4. Protocol records, verifies and settles
Ghast Protocol binds the purchase to those terms, records the result and evidence, evaluates delivery against the claim, and resolves payment. The run creates an Execution Record linking the purchase, the version, the report and the Delivery Evidence. Verification then asks one question: does the evidence show that the claim was met? It has three possible answers: claim met, claim not met or indeterminate.
A claim-met result is provisional. It enters a three-day public Challenge Window, during which anyone can file a Challenge by posting a Challenge Bond. If the window closes unchallenged, or if Evidence Review upholds the result, the delivery becomes protocol-final. Had a report been missing severity ratings, the result would be claim not met. Pending payment would be refunded, and once the breach was confirmed, the reserved Creator Bond exposure would be slashed. Capability Lifecycle and Challenges and Disputes give the full rules.
What verification covers is limited to the claim. This review claim says nothing about finding every vulnerability, so a verified delivery does not certify the code as secure. Any promise about coverage needs its own criterion in the claim. Security and Risk sets out this boundary.
5. The outcome becomes history
Each execution and its outcome become part of that service’s Capability History. The record shows what ran, under which version and claim, how delivery was evaluated and how payment resolved, including failures, refunds and disputes. A separate Verified Delivery History holds only the protocol-final, claim-met outcomes. Reputation and Delivery History explains why the two records are kept apart.
That history is what the rest of the system reads. A later buyer reviews it before purchasing. Agents and applications that offer the Capability show the same history under the same identity, as described in Distribution and Integration. After enough verified deliveries and recurring revenue, the service can qualify for Capability Financing to fund more execution capacity.
Who does what
| Step | Creator | Buyer | Protocol |
|---|---|---|---|
| Build | Develops the workflow in Workbench | — | — |
| Publish | Writes claim, price and evidence rules; posts bonds | — | Validates the claim |
| Purchase | — | Pays and supplies inputs | Binds the version and terms |
| Execute | Runs the private workflow | — | Creates the Execution Record |
| Verify and settle | — | May accept or challenge | Evaluates evidence and resolves payment |
| History | Builds a service-level record | Reads it before the next purchase | Keeps both histories |
Questions
Does the buyer ever see the Creator’s prompts or workflow?
No. The buyer sees the claim, the result and the Delivery Evidence the claim requires. Prompts, private knowledge, memory and execution strategy stay with the Creator unless the Creator chooses to disclose them.
What happens if a delivery misses its claim?
Verification returns claim not met and the delivery goes to Evidence Review. If the breach is confirmed, pending payment is refunded, the Creator Bond is slashed and the outcome is recorded in the service’s Capability History.