Privacy Model
A buyer needs enough information to decide whether to pay and to check what was delivered. A Creator needs the method that produced the work to stay private, because that method is what the Creator is selling. Ghast Protocol, which is in development, draws the line between the two as follows.
Three privacy layers
Service terms are public. Access to methods, data and execution is controlled, in three layers:
| Layer | What stays controlled |
|---|---|
| Method | Proprietary prompts, knowledge and execution logic remain Creator-controlled. |
| Transaction | Inputs, outputs and raw evidence are shared only with authorized parties and reviewers. |
| Compute | Confidential execution runs on supported, attested runtime paths. |
Together, the three layers let an expert AI service be called by people and agents, through the channels in Distribution and Integration, without exposing how it works. The sections below set out the method and transaction boundaries in detail.
Disclosure boundary
A Capability discloses the service contract and evidence needed to evaluate delivery while keeping the Creator’s method under the Creator’s control.
| Information | Visibility | Purpose |
|---|---|---|
| Capability description, Defined Claim, price, and version | Buyer-visible; public when distributed through a public channel | Define the purchase |
| Evidence requirements and settlement conditions | Buyer-visible before purchase | Define assessment and recourse |
| Prompts, private knowledge, memory, data logic, and execution strategy | Creator-controlled | Protect the method |
| Buyer inputs and execution outputs | Authorized transaction participants | Complete the work |
| Execution ID, Capability version, provisional result, Challenge deadline, and claim-relevant evidence commitment or summary | Public during the Challenge Window | Make the public Challenge Window usable |
| Raw Execution Record and Delivery Evidence | Transaction parties and authorized reviewers | Support Verification and Evidence Review |
| Resolved outcomes and aggregate Capability History | Public summary; sensitive transaction detail remains access-controlled | Support Buyer diligence across channels |
Each row exists so a later step in the transaction can happen without exposing something that belongs to someone else. The buyer reads the Defined Claim and the evidence rules before paying, because terms that appear only after payment are not a contract. The method stays with the Creator because the buyer is purchasing a defined service, not a copy of the workflow. The public Challenge Window needs a narrow public record, or nobody outside the transaction could file a Challenge, as Challenges and Disputes describes.
Who sees what in one purchase
Take the software security review from Capability Examples.
- Anyone browsing the listing sees the description, the Defined Claim, the price, the version, and the evidence and settlement rules. A prospective buyer can tell exactly what the service promises without seeing how it works.
- The Buyer supplies a commit hash and a list of directories, and receives the report together with its Delivery Evidence: the repository revision and scope, input and output manifests, and findings mapped to file locations. The buyer’s code is an input to this job and never becomes part of the listing.
- The Creator runs the static-analysis and dependency-review agents, with their playbooks, prompts and prioritization rules. None of that leaves the Creator’s workspace.
- The public, during the three-day Challenge Window, sees the execution ID, the version, the provisional result, the deadline and a commitment to the claim-relevant evidence. That is enough to know a challengeable result exists, but it reveals neither the buyer’s code nor the report.
- A Resolver, one of the roles in Actors and Core Objects, if a Challenge is filed, sees the raw Execution Record and Delivery Evidence under the review’s access rules, and nothing about the method that the claim does not require.
- Later buyers see the resolved outcome in the service’s Capability History, described in Reputation and Delivery History, aggregated with the other executions, without the details of this transaction.
Evidence access
Delivery Evidence is limited to what the Defined Claim requires. Public metadata supports discovery and Challenge filing; raw evidence is available only to the parties and Resolver under the applicable access and retention rules.
This limit keeps evidence useful without making it a leak. If a claim requires a diff and a passing test run, the evidence is that diff and that test result, not a trace of every prompt that produced them. The limit also sets what a verified result means. Verification, as Evidence and Verification defines it, confirms the claim, and it says nothing about parts of the workflow the evidence does not cover. Security and Risk explains that boundary.
Privacy controls
Claims, records, outputs, and evidence follow the access, retention, and disclosure rules defined for the applicable Capability. Private workflow logic remains Creator-controlled unless the Creator expressly authorizes disclosure.
Disclosure of the method is always a deliberate act by the Creator. Listing a service does not disclose it, and neither does losing a Challenge. Retention follows the same logic. Evidence a Resolver needed during a dispute does not become a permanent public archive of the buyer’s inputs.
Workbench privacy is a separate question
These rules govern Capability transactions. Ghast Workbench, the live desktop product, has its own data handling. Projects stay in a local workspace, model requests send the prompt and selected context to the configured provider, and encrypted backups are opt-in. The privacy policy describes what leaves the device for each feature.
Questions
Does publishing a Capability expose the Creator’s prompts or workflow?
No. Prompts, private knowledge, memory, data logic and execution strategy stay Creator-controlled. Buyers see the description, Defined Claim, price, version, and the evidence and settlement rules.
Who can see the inputs a buyer sends?
Only the authorized participants in that transaction, and a Resolver if a Challenge goes to Evidence Review. Buyer inputs are never part of the public listing or the public Challenge Window record.