How the demos work
The demos run three applications behind one local Model Context Protocol (MCP) server. An AI agent calls their actions as tools through its client and reports the results in conversation. MCP is only the demo's interface. GAP works with any interface: an implementation can use another interface and another way of storing records while producing the same GAP records.
To connect a client, follow Run the demos. To understand the content and roles without running anything, pick a domain guide.
- The demo runs on your computer for one user. It is not a production system.
- You play the roles in the walkthrough by telling the agent who you are acting as. The agent uses the participant configured for that role, and the application checks that participant's permissions.
- Choosing a role does not sign you in or verify your identity. The demo's permission checks and audience labels do not protect access to the local files.
- The examples use made-up data. Use fictional content when you try your own examples.
Client, tools, and application state
The client connects over Streamable HTTP and finds every registered tool. Each tool's description names its application and the lifecycle steps and release decisions it declares. The same declarations appear in the MCP metadata and in the generated reference below. Connecting to the server grants no GAP permission; each application checks the actor and action against its own configuration.
Call describe_demo to see the applications and their tools grouped by purpose. It returns server information, lifecycle and decision labels, and the application groups with action names, titles, and declarations. Input schemas arrive through MCP tool discovery and are shown in the reference below.
Each application keeps its own JSON workspace. The first start creates any missing workspace from made-up seed data, and later restarts keep it. No database, cloud account, or internal service is needed. Each application writes its own records, checks its own permissions, and runs its own verification. The layer they share describes and validates each action's declarations and exposes actions as tools; it performs no lifecycle step and verifies no record.
Start with a domain's workflow
| Application | Initial configuration | Walkthrough |
|---|---|---|
Blog website (cms) | Propose the blog-post model, preview it, and ratify that exact revision before saving a post. The workspace also includes example data for the generic CMS tools. | Draft, review, release, and read a post |
Issue tracking (issue-tracking) | get_ticket_workflow returns the already ratified bug-ticket model, participant permissions, and the app's rules for choosing the current version. | Create, edit, and complete a ticket |
Research publishing (research) | get_research_workflow returns the already ratified models, participant permissions, the journal and cited-works trust stores, and the app's rules for choosing the current version. | Review, publish, and verify a gummy-worm recall paper |
The CMS's derived-content tools include experiments with dependencies beyond what the draft requires. The tool descriptions identify these experiments.
Identifiers in the examples
The demo uses readable strings to distinguish kinds of records and participants:
| Example | What it identifies |
|---|---|
cms.article or blog-post | A profile: the rules for one kind of content. |
blog-post:monarch-migration | An artifact whose saved versions share that ID. |
agent:writer or human:publisher | A participant configured in this application. The actor record also carries its kind explicitly. |
These prefixes are local naming conventions. A string such as human:publisher grants no permission on its own; the application checks its participant configuration. The profile ID and revision identify the rules, while the digest pins their exact contents.
When authoring your own examples, choose an ID that is unambiguous in the application’s record store, retain the same artifact ID for later versions of the same content, and keep profile IDs separate from artifact IDs. Use the participant IDs configured by the demo. GAP’s record schemas require non-empty ID strings; they do not prescribe these prefixes.
What tools return
Successful tool calls return the action's result in two MCP forms: a text block containing JSON, and structuredContent. Objects remain objects in structuredContent; arrays are wrapped as { items: [...] }, and scalar values as { value: ... }. Those wrappers are interface details, not GAP records.
A successful call does not always mean a release occurred. Read the returned record and the action's declarations:
| Result | What it establishes |
|---|---|
| A proposal, working copy, list, or preview | Application state or material for a decision. A preview grants no authority. A working copy is not an artifact version. |
| An artifact version from a draft save | The saved content and a reference to the exact profile revision it follows. The version cannot be edited in place, and this record alone does not establish whether it has been released. |
| An approval or rejection | An authority's decision about an exact version. Neither decision releases it. |
| A release proof | The released content, exact profile revision, authorization, and any recorded approvals or rejections included for that version. The consumer checks the content against profile rules it supports and the decisions against its configured trust. |
| A verification result | The checks that verifier performed, within its stated limits. It is not evidence of content accuracy or downstream delivery. |
For actions that use a preview, the client keeps the returned confirmation and any expected-version value. The person reviews the content and decides in ordinary language, without copying digests or confirmation strings. Those strings tie a request to its preview; they don't identify the person using the client.
Outputs in the walkthroughs
- Blog website:
read_postreturns the selected headline and body, locale selection and fallback details, and the full release proof. Authorization covers all locales in the payload.displayOutcomeisnot-performed-or-proved: the demo has not published or displayed a website. The records name the configured actors who made each decision, but they are unsigned and cannot independently authenticate those actors. - Issue tracking: create and save actions return a release proof.
list_current_ticketsreturns a proof for each ticket's most recently saved version;get_ticket_historyreturns proofs for every released version of that ticket. A working-copy read instead returns staged content, validation problems, changed fields, the current version, and a stale flag. It has no release proof. The completion reason records the assignee's account of a check, not evidence that the bug is fixed. The app records the configured actor who saved the change; it does not authenticate the participant or sign the decision. - Research publishing:
read_researchreturns an array of release proofs. When a request for the selected publication finds a withdrawn release, that entry contains only the withdrawal record. A request for a specific version returns its proof with any withdrawal attached.verify_research_prooftakes one returned record, not the whole array, and reportsverifiedorwithdrawnwith the subject and signer information; failed checks raise an error. The verifier uses the supplied records and trust store without reading the workspace. If no trust store is supplied, it uses the demo's configured store. The reader chooses which keys to trust separately from the proof being checked. - Source checks:
sweep_research_sourcesreportsaligned,drift,integrity-failure, orunresolvedfor a paper's source references. It edits no paper or release decision. Verifying a paper's own proof does not verify its dependencies; source proofs must be obtained and checked separately. A drift finding does not prove the paper's wording is wrong.
The research verifier exercises checking signed records without access to the workspace. All these tools still come from one local demo built by one team. They do not demonstrate interoperability between independently built systems or production key management.
Tool reference
Every registered tool appears below, grouped by application and then by workflow. The list is generated from the demo's own manifest when the site is built. Open a tool for its description and input fields. Tool names and application IDs are the ones the client sees; the blog website application's ID is cms.
Lifecycle steps and release decisions
Beside each tool is a label for every lifecycle step it performs and every release decision it records, linking to that step in the specification. A tool with no label reads, previews, edits a working copy, or checks.
- Step 1: Propose a profile Say what fields the content must follow.
- Step 2: Ratify a revision Approve one exact profile revision.
- Step 3: Create a version Save an immutable version of the content.
- Step 4: Authorize Permit release of one exact version.
- Step 5: Release Make the authorized version available to readers.
- Step 6: Read and verify Read it back and check its proof.
Release decisions are records an authority adds beside the steps, not steps of their own, so their labels carry a diamond.
- Release decision: Approval Record that a version is approved for release, before it is authorized.
- Release decision: Rejection Record that a version is not approved, before it is authorized.
- Release decision: Withdrawal Record that a released version should no longer be relied on.
Demo server
Tools about the demo itself: what it hosts, and how to reset an application’s local workspace.
Demo server
Discover the applications and reset local state.
describe_demoDescribe the demoNone
List the applications this server hosts, their tools grouped the way the documentation presents them, and the GAP lifecycle steps and release decisions each tool declares. Read this first to find the tools for the domain you are working in.
No input.
reset_demo_workspaceReset a demo workspaceNone
Explicitly reset one application’s local demo workspace, or every application’s, to checked-in synthetic seed data. This destroys that application’s state and is never run during normal startup. Only call it when the human asks to discard the demo data.
| Field | Type | Notes |
|---|---|---|
application | "cms" | "issue-tracking" | "research" | "all" | |
confirm | exactly "reset synthetic demo workspace" |
Blog website
A content management system for a blog. Writers save drafts, an editor approves or rejects a version, a publisher releases it, and a website reads it back with its proof.
Blog post walkthrough
The actions the blog walkthrough uses, from proposing the content model to reading a published post.
propose_blog_modelPropose the blog post modelStep 1: Propose a profile
Propose the domain guide blog-post model: author, the byline date-time, the CMS audience label, and a content map keyed by BCP 47 locale tag that allows en-US, es-US, en-MX, and es-MX; requires en-US and es-MX; and declares es-US falling back to en-US and en-MX to es-MX. Propose the next revision without changing existing profiles or posts. Review and ratify this exact proposal before saving under it; this action does not approve the model.
| Field | Type | Notes |
|---|---|---|
proposedBy | { actorId: string (min 1); actorKind: "agent" | "human" } |
save_blog_postSave a blog post draftStep 3: Create a version
Save an immutable blog-post draft under the ratified model. date is the byline date and time as an RFC 3339 date-time such as 2026-10-26T09:30:00Z; content maps locale tags to a headline and body; a minimal post carries en-US and es-MX. Missing US Spanish falls back to US English; missing Mexican English falls back to Mexican Spanish. Every required locale must be present and only allowed locales are accepted, or nothing is stored. Use expectedVersion 0 for a new ID or the last saved draft version for edits. Locale content is part of the payload, so one later publish covers every locale in the version; there is no per-locale publish. Save preserves history and grants no publish authority.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1) | |
expectedVersion | integer (min 0) | |
author | string (min 1, max 5000) | |
date | string (date-time) | |
audience | "public" | "members" | "internal" | |
content | object keyed by string | |
authoredBy | { actorId: string (min 1); actorKind: "agent" | "human" } |
preview_release_approvalPreview a version for approvalNone
Review the exact saved blog-post version an approver is deciding on: identity, version, payload, payload digest, profile pin, subject digest, the configured approval authorities, and the required APPROVE confirmation. This grants no authority and releases nothing.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1) | |
artifactVersion | integer (greater than 0) |
approve_postApprove a versionRelease decision: Approval
Record a release approval of the exact saved blog-post version reviewed with preview_release_approval, naming the configured approval authority in approvedBy. When the approver states why, carry it as reason: plain language stored on the approval, not evidence that the post is correct, and outside every digest. Approval releases nothing and grants no publish authority; publish_post still needs a configured release authority. Carry the APPROVE confirmation after contextual approval; do not ask for a second approval or transcription.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1) | |
artifactVersion | integer (greater than 0) | |
approvedBy | { actorId: string (min 1); actorKind: "agent" | "human" } | |
confirmation | string (min 1) | |
reason optional | string | plain language, not blank, at most 5000 characters |
reject_postReject a versionRelease decision: Rejection
Record a release rejection: a configured approval authority named in rejectedBy decides that the exact saved blog-post version is not approved. The record binds the version as stored, with its subject digest. This CMS requires a reason: the plain-language basis for not approving, attributed text that is not evidence the post is wrong. Rejecting releases, withdraws, and blocks nothing; a later approval or publish of the same version is still checked only against configured authority, and a proof of that version then carries the rejection beside the approval.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1) | |
artifactVersion | integer (greater than 0) | |
rejectedBy | { actorId: string (min 1); actorKind: "agent" | "human" } | |
reason | string | plain language, not blank, at most 5000 characters |
list_post_rejectionsList the rejections of a postNone
List the release rejections recorded for one blog post: which exact version each binds, who declined, when, and why. A rejection of an unreleased version is readable here and nowhere else; once a version with rejections is published, its proof carries them.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1) |
publish_postPublish a versionStep 4: AuthorizeStep 5: Release
Publish the exact saved blog-post version reviewed with preview_release_authorization. A configured release authority supplies authorization and release in one action; the local blog-post policy requires a release approval of this exact version first, and the proof carries that approval. When the publisher states why, carry it as reason: plain language stored on the authorization, not evidence of anything, and outside every digest. Carry the AUTHORIZE preview confirmation after contextual approval; do not ask for a second approval or transcription. This demo permits one released version per post ID and does not publish a website.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1) | |
artifactVersion | integer (greater than 0) | |
authorizedBy | { actorId: string (min 1); actorKind: "agent" | "human" } | |
confirmation | string (min 1) | |
reason optional | string | plain language, not blank, at most 5000 characters |
read_postRead a published postStep 6: Read and verify
Read one released blog post for the exact audience label, verify its release proof, then select the requested locale or the fallback the profile declares for it. Selection is delivery, not a GAP step: the authorization covers the entire payload, every locale, and the result labels display as not performed or proved. A locale outside the model is refused.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1) | |
audience | "public" | "members" | "internal" | |
locale | string (min 1) |
Any CMS content model
The lower-level CMS tools the blog actions are built on. They work for any content model: propose and ratify profiles, create versions, authorize and release, read records and proofs.
get_cms_capabilitiesDescribe this CMSNone
Discover machine-readable implementation-local contract limits, content-audience semantics, storage boundaries, and release-model limits before proposing profiles or describing release state.
No input.
propose_profilePropose a profileStep 1: Propose a profile
Create one immutable, non-authoritative profile proposal using the bounded local contract language. Call get_cms_capabilities first for exact supported limits. Proposal never grants authority or advances the ratified head.
| Field | Type | Notes |
|---|---|---|
profileId | string (min 1) | |
revision | integer (greater than 0) | |
payloadContract | object keyed by string | |
proposedBy | { actorId: string (min 1); actorKind: "agent" | "human" } |
list_profile_proposalsList profile proposalsNone
get_profile_proposalRead a profile proposalNone
Read one exact immutable, non-authoritative profile proposal.
| Field | Type | Notes |
|---|---|---|
profileId | string (min 1) | |
revision | integer (greater than 0) |
preview_profile_ratificationPreview a proposal for ratificationNone
Review one exact proposal, its profile digest, configuration audience, seeded release policies, and opaque confirmation. This grants no authority.
| Field | Type | Notes |
|---|---|---|
profileId | string (min 1) | |
revision | integer (greater than 0) |
ratify_profileRatify a profile revisionStep 2: Ratify a revision
Ratify one exact reviewed proposal under configured attributed-human configuration authority. After the human clearly approves the exact preview in context, carry the opaque preview confirmation yourself; do not require magic wording or ask the human to transcribe it. When the human states why, carry it as reason: plain language stored on the ratification, outside the profile digest, and not evidence of anything.
| Field | Type | Notes |
|---|---|---|
profileId | string (min 1) | |
revision | integer (greater than 0) | |
ratifiedBy | { actorId: string (min 1); actorKind: "agent" | "human" } | |
confirmation | string (min 1) | |
reason optional | string | plain language, not blank, at most 5000 characters |
list_profilesList ratified profilesNone
List ratified CMS profile revisions with exact digest pins; contract bodies are omitted.
No input.
get_profile_revisionRead a ratified profile revisionNone
Read one exact ratified CMS profile revision and its bounded payload contract.
| Field | Type | Notes |
|---|---|---|
profileId | string (min 1) | |
revision | integer (greater than 0) |
list_release_authority_policiesList release authority policiesNone
List the exact local release-authority policies configured by profile revision, actor identity and kind, and application audience. Authorship or confidence never creates authority.
No input.
create_artifact_versionCreate an artifact versionStep 3: Create a version
Create one immutable governed artifact version pinned to an exact or current ratified profile revision. This does not authorize or release it.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1) | |
artifactVersion | integer (greater than 0) | |
profileId | string (min 1) | |
profileRevision optional | integer (greater than 0) | |
payload | any | |
authoredBy | { actorId: string (min 1); actorKind: "agent" | "human" } |
get_artifact_versionRead an artifact versionNone
Read one exact immutable artifact version inside the authoring boundary. The record does not contain or imply release status; query list_releases or get_release_proof separately before describing it as released.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1) | |
artifactVersion | integer (greater than 0) |
list_artifact_versionsList artifact versionsNone
List concise immutable artifact-version summaries inside the authoring boundary. This is not a consumer release read.
No input.
get_raw_recordRead one raw recordNone
Retrieve one exact full raw record by identity instead of listing large collections. Artifact records do not imply release status; select releaseProof separately to establish a release.
| Field | Type | Notes |
|---|---|---|
recordType | "profileProposal" | "profileRevision" | "artifactVersion" | "releaseProof" | |
profileId optional | string (min 1) | profileProposal and profileRevision |
revision optional | integer (greater than 0) | profileProposal and profileRevision |
artifactId optional | string (min 1) | artifactVersion and releaseProof |
artifactVersion optional | integer (greater than 0) | artifactVersion |
audience optional | "public" | "members" | "internal" | releaseProof |
preview_release_authorizationPreview a version for authorizationNone
Review the exact artifact identity, version, payload, payload digest, profile pin, subject digest, and required confirmation. This grants no authority.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1) | |
artifactVersion | integer (greater than 0) |
authorize_and_releaseAuthorize and release a versionStep 4: AuthorizeStep 5: Release
Atomically create the sole release for one exact reviewed artifact version under a configured authority policy. This implementation cannot replace, supersede, or withdraw an existing release and does not define a current release. After the authority clearly approves the exact preview in context, carry its opaque confirmation yourself; do not require magic wording or ask the human to transcribe it. When the authority states why, carry it as reason: plain language stored on the authorization, outside every digest, and not evidence of anything.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1) | |
artifactVersion | integer (greater than 0) | |
authorizedBy | { actorId: string (min 1); actorKind: "agent" | "human" } | |
confirmation | string (min 1) | |
reason optional | string | plain language, not blank, at most 5000 characters |
list_releasesList releases for an audienceStep 6: Read and verify
List verifiable released artifacts eligible for the exact application audience label. Drafts are never returned.
| Field | Type | Notes |
|---|---|---|
audience | "public" | "members" | "internal" |
get_release_proofRead a release proofStep 6: Read and verify
Read one released artifact and its verification records for the exact application audience label. Drafts are never returned.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1) | |
audience | "public" | "members" | "internal" |
verify_release_proofVerify a release proofStep 6: Read and verify
Verify a supplied CMS release proof by checking exact shapes, references, profile and payload digests, bounded content, and actor attribution.
| Field | Type | Notes |
|---|---|---|
proof | { profile: { profileId: string; revision: number; payloadContract: object keyed by string; digest: string; ratification: object }; authorization: { artifactId: string; artifactVersion: number; payloadDigest: string; profile: object; authorizedAt: string; authorizedBy: object; reason?: string; authorizationSubjectDigest: string }; release: { artifactId: string; artifactVersion: number; payload: any; profile: object }; approvals?: array of object; rejections?: array of object } |
Derived content and external dependencies
Rendering a released article into a new draft, and checking external image pins. These exercise a non-normative dependency candidate.
render_released_articleRender a released articleStep 6: Read and verifyStep 3: Create a version
Deterministically transform one verified released cms.article into a new immutable draft under the distinct local cms.rendered-article profile. The draft carries a candidate GovernedDependencyPin for the exact source. Rendering does not authorize or release the derivative and does not display it.
| Field | Type | Notes |
|---|---|---|
sourceArtifactId | string (min 1) | |
sourceAudience | "public" | "members" | "internal" | |
renderedArtifactId | string (min 1) | |
renderedArtifactVersion | integer (greater than 0) | |
authoredBy | { actorId: string (min 1); actorKind: "agent" | "human" } |
verify_rendered_artifactVerify a rendered article against its sourceStep 6: Read and verify
Verify both release proofs under normative GAP core, exact GovernedDependencyPin matching under the non-normative #91 candidate, and deterministic renderer/template/locale bytes under implementation-local semantics. Returns machine-readable classifications and states that later display was not proved.
| Field | Type | Notes |
|---|---|---|
renderedProof | { profile: { profileId: string; revision: number; payloadContract: object keyed by string; digest: string; ratification: object }; authorization: { artifactId: string; artifactVersion: number; payloadDigest: string; profile: object; authorizedAt: string; authorizedBy: object; reason?: string; authorizationSubjectDigest: string }; release: { artifactId: string; artifactVersion: number; payload: any; profile: object }; approvals?: array of object; rejections?: array of object } | |
sourceProof | { profile: { profileId: string; revision: number; payloadContract: object keyed by string; digest: string; ratification: object }; authorization: { artifactId: string; artifactVersion: number; payloadDigest: string; profile: object; authorizedAt: string; authorizedBy: object; reason?: string; authorizationSubjectDigest: string }; release: { artifactId: string; artifactVersion: number; payload: any; profile: object }; approvals?: array of object; rejections?: array of object } |
inspect_gallery_external_dependenciesInspect a gallery’s external pinsStep 6: Read and verify
Verify a released cms.external-image-gallery proof, then report every #91 candidate ExternalDependencyPin as unverified because no external bytes were supplied. A pin in a valid release is only a governed claim, not verified external content.
| Field | Type | Notes |
|---|---|---|
galleryProof | { profile: { profileId: string; revision: number; payloadContract: object keyed by string; digest: string; ratification: object }; authorization: { artifactId: string; artifactVersion: number; payloadDigest: string; profile: object; authorizedAt: string; authorizedBy: object; reason?: string; authorizationSubjectDigest: string }; release: { artifactId: string; artifactVersion: number; payload: any; profile: object }; approvals?: array of object; rejections?: array of object } |
verify_gallery_external_dependencyVerify one external image pinStep 6: Read and verify
Verify one released gallery proof, then apply the non-normative #91 ExternalDependencyPin candidate by hashing independently supplied exact raw bytes. Bytes are base64 only for MCP transport; retrieval, availability, and governance of the external content are not proved.
| Field | Type | Notes |
|---|---|---|
galleryProof | { profile: { profileId: string; revision: number; payloadContract: object keyed by string; digest: string; ratification: object }; authorization: { artifactId: string; artifactVersion: number; payloadDigest: string; profile: object; authorizedAt: string; authorizedBy: object; reason?: string; authorizationSubjectDigest: string }; release: { artifactId: string; artifactVersion: number; payload: any; profile: object }; approvals?: array of object; rejections?: array of object } | |
imageIndex | integer (min 0) | |
contentBase64 | string |
Issue tracking
An issue tracking app where creating or saving a ticket creates, authorizes, and releases a version in one action, and an assignee can iterate on a working copy first.
Bug ticket walkthrough
The bug ticket walkthrough: inspect the workflow, create a ticket, update or complete it, and read the current ticket or its history.
get_ticket_workflowInspect the ticket workflowNone
Discover the pre-ratified bug-ticket content model and configured create, update, and completion permissions for the guide workflow. Local actor attribution is not authentication.
No input.
create_ticketCreate a ticketStep 3: Create a versionStep 4: AuthorizeStep 5: Release
Create, authorize, and release a To do bug ticket in one application action. Use the configured requester actor. The request to create supplies authorization; there is no separate approval interaction.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1, max 200) | |
payload | { title: string (min 1, max 5000); description: string (min 1, max 5000); acceptanceCriteria: array of string (min 1, max 5000) (max 20); status: "to_do" | "in_progress" | "done" } | |
actor | { actorId: string (min 1); actorKind: "human" | "agent" } |
update_ticketUpdate or complete a ticketStep 3: Create a versionStep 4: AuthorizeStep 5: Release
Update, authorize, and release the next immutable bug-ticket version immediately using configured update authority. Carry expectedVersion from the last read; stale updates fail. Send completionEvidence only when marking the ticket Done: completing requires it, and any other save that includes it is refused. Preserve earlier content and proofs.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1, max 200) | |
expectedVersion | integer (greater than 0) | |
payload | { title: string (min 1, max 5000); description: string (min 1, max 5000); acceptanceCriteria: array of string (min 1, max 5000) (max 20); status: "to_do" | "in_progress" | "done" } | |
actor | { actorId: string (min 1); actorKind: "human" | "agent" } | |
completionEvidence optional | string (min 1, max 5000) | A description of the check performed, recorded as the authorization reason. Send it only when marking the ticket Done; a save with any other status that includes it is refused. |
list_current_ticketsList current ticketsStep 6: Read and verify
Read verified bug-ticket releases selected by the application-local save ledger. Current selection is not portable GAP supersession.
No input.
get_ticket_historyRead a ticket’s historyStep 6: Read and verify
Read every exact released bug-ticket version and its proof, preserving earlier payloads, criteria, and status.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1, max 200) |
Working copies
Stage and iterate on a working copy before saving. A working copy is application state, not a GAP record.
stage_ticket_changesStage a working copyNone
Stage or replace a mutable working copy of one released ticket to iterate on before saving. The payload replaces the whole working copy, so send every field you want to keep, copied from the version you read. A working copy is not an artifact version and not a GAP record: staging creates no version, no authorization, and no release, and the ticket and its history do not change. Any configured participant may stage; staging grants no authority to save. Carry expectedVersion from the last read. The response reports validation against the pinned content model and the fields that differ from the current version.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1, max 200) | |
expectedVersion | integer (greater than 0) | |
payload | { title?: string; description?: string; acceptanceCriteria?: array of string; status?: "to_do" | "in_progress" | "done" } | Staged bug-ticket content. It may be incomplete or out of bounds while you iterate; the response reports validation against the pinned content model, and only a valid working copy can be saved. |
actor | { actorId: string (min 1); actorKind: "human" | "agent" } |
get_ticket_working_copyRead a working copyNone
Read the staged working copy for one ticket with its validation result, the fields that differ from the current released version, and whether it is stale. This is not a read of the ticket: the working copy is not an artifact version and has no release evidence.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1, max 200) |
discard_ticket_working_copyDiscard a working copyNone
Discard the staged working copy for one ticket. Nothing is created and the ticket does not change.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1, max 200) | |
actor | { actorId: string (min 1); actorKind: "human" | "agent" } |
save_ticket_changesSave a working copy as a versionStep 3: Create a versionStep 4: AuthorizeStep 5: Release
Save the staged working copy: create, authorize, and release the next immutable bug-ticket version from it in one application action, using configured update authority, then remove the working copy. Fails if the working copy is missing, invalid, or stale. Send completionEvidence only when marking the ticket Done: completing requires it, and any other save that includes it is refused.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1, max 200) | |
actor | { actorId: string (min 1); actorKind: "human" | "agent" } | |
completionEvidence optional | string (min 1, max 5000) | A description of the check performed, recorded as the authorization reason. Send it only when marking the ticket Done; a save with any other status that includes it is refused. |
Research publishing
A fictional paper asking whether floating gummy worms remember stories better, built on a previously published pace study and a recall-quiz methods paper, with exact citations, distinct peer review and editor notes, a source correction, signed editorial approval, and one final publication.
Gummy-worm recall walkthrough
Publish a synthetic paper on whether floating gummy worms remember stories better, after peer feedback and editorial approval; preserve the prior work it cites and verify signed records independently.
get_research_workflowInspect the journal workflowNone
Discover pre-ratified source, paper, peer-review, and editor-notes profiles, local journal permissions and publication policy, demonstration key custody, and the journal and cited-works trust stores a reader configures. All studies and results are fictional.
No input.
save_research_sourceSave a study or methods paperStep 3: Create a version
Save immutable source material: a fictional reference study or reusable methods paper. Both use the source profile and must be released before a paper can pin them. Saving grants no release authority.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1, max 200) | |
payload | { kind: "study" | "methods-paper"; title: string (min 1, max 5000); authors: array of string (min 1, max 5000) (min 1, max 20); journal: string (min 1, max 5000); year: integer (min 1900, max 2100); body: string (min 1, max 5000) } | |
actor | { actorId: string (min 1); actorKind: "human" | "agent" } |
save_research_paperSave a manuscript versionStep 3: Create a version
Save a complete immutable manuscript, bibliography, review responses, and ordered exact dependency set. Local policy requires released study material and one methods paper. Capture the versions actually used; never substitute a newer source. Credited authors belong in payload.authors; actor identifies who saves.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1, max 200) | |
payload | { title: string (min 1, max 5000); authors: array of string (min 1, max 5000) (min 1, max 20); abstract: string (min 1, max 5000); sections: array of object (min 1, max 20); bibliography: array of object (min 1, max 20); reviewResponses: array of object (max 40); editorResponses: array of object (max 40); dependencySet: { entries: array of object (min 1, max 20) } } | |
actor | { actorId: string (min 1); actorKind: "human" | "agent" } |
save_research_reviewSave a peer-review reportStep 3: Create a version
Save one report over the exact stored manuscript identity, payload digest, and profile pin. Section IDs and quotes must match that version. A draft manuscript reference is local domain content, not a dependency-set entry. Recommendation and feedback confer no publication authority.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1, max 200) | |
payload | { manuscript: { artifactId: string (min 1, max 200); artifactVersion: integer (greater than 0); payloadDigest: string; profile: object }; reviewer: string (min 1, max 5000); recommendation: "revise" | "accept"; feedback: array of object (min 1, max 20) } | |
actor | { actorId: string (min 1); actorKind: "human" | "agent" } |
save_research_editor_notesSave editor notesStep 3: Create a version
As configured journal editor, save notes under their own profile over an exact manuscript version and matching section quotes. Releasing notes shares feedback; it does not approve, reject, or publish the manuscript. Notes are distinct from peer-review reports and authority decisions.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1, max 200) | |
payload | { manuscript: { artifactId: string (min 1, max 200); artifactVersion: integer (greater than 0); payloadDigest: string; profile: object }; editor: string (min 1, max 5000); feedback: array of object (min 1, max 20) } | |
actor | { actorId: string (min 1); actorKind: "human" | "agent" } |
preview_research_releasePreview a version for a decisionNone
Show the exact stored version, its subject digest, and current release selection. Carry the release, approval, or rejection confirmation for the relevant action as client state after contextual review; do not ask the person to transcribe it. Preview records no decision and releases nothing.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1, max 200) | |
artifactVersion | integer (greater than 0) | |
actor | { actorId: string (min 1); actorKind: "human" | "agent" } |
approve_research_paperApprove a manuscript for publicationRelease decision: Approval
As configured journal editor, sign approval of the exact previewed manuscript. Local policy requires a released report and responses to each pinned comment. Approval releases nothing and gives no publication authority; later edits require their own approval. A published version cannot be approved again. An optional reason is explanation outside the signed digest.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1, max 200) | |
artifactVersion | integer (greater than 0) | |
actor | { actorId: string (min 1); actorKind: "human" | "agent" } | |
confirmation | string (min 1) | |
reason optional | string (min 1, max 5000) |
reject_research_paperDecline a manuscript versionRelease decision: Rejection
As configured journal editor, sign rejection of one exact previewed manuscript. Add a record preserving the manuscript and any earlier decisions. Rejection does not release or withdraw anything and does not itself prevent later approval of the same subject. A published version takes no further decisions; withdraw it instead. A peer recommendation is separate from this authority decision.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1, max 200) | |
artifactVersion | integer (greater than 0) | |
actor | { actorId: string (min 1); actorKind: "human" | "agent" } | |
confirmation | string (min 1) | |
reason optional | string (min 1, max 5000) |
release_researchRelease source material or a report, or publish a paperStep 4: AuthorizeStep 5: Release
The configured authority signs authorization and releases the exact previewed version in one recoverable local transition. The cited-works editor releases source material; the journal publisher releases review reports, editor notes, and papers, and publishes a paper only after exact editorial approval. Preserve earlier records and append the local current selection. This synthetic demo does not send papers to a journal.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1, max 200) | |
artifactVersion | integer (greater than 0) | |
actor | { actorId: string (min 1); actorKind: "human" | "agent" } | |
confirmation | string (min 1) | |
expectedCurrentVersion | integer (min 0) |
read_researchRead released researchStep 6: Read and verify
Return verified release proofs for selected or exact historical versions. Drafts cannot be read here. A selected withdrawn paper returns its withdrawal alone; an exact read returns the unchanged original proof with the withdrawal attached. All released demonstration content is public.
| Field | Type | Notes |
|---|---|---|
artifactId optional | string (min 1, max 200) | |
artifactVersion optional | integer (greater than 0) |
verify_research_proofVerify a proof against reader trustStep 6: Read and verify
Check one supplied release proof or standalone withdrawal using its bytes and the reader’s trust store: the journal store for papers, reports, and notes, the cited-works store for sources. Recompute digests, validate the pinned JSON Schema contract, and verify every carried authority signature. Read no workspace or signing keys. Verification establishes release decisions, not research correctness.
| Field | Type | Notes |
|---|---|---|
proof | object keyed by string | |
trustStore | object keyed by string |
withdraw_research_paperWithdraw a published paper versionRelease decision: Withdrawal
As configured publisher, add a signed withdrawal of one exact published paper. Preserve its content, approvals, rejections, authorization, release, and source baseline. Withdrawal selects no replacement. The optional reason explains the decision and is outside its signature.
| Field | Type | Notes |
|---|---|---|
artifactId | string (min 1, max 200) | |
artifactVersion | integer (greater than 0) | |
actor | { actorId: string (min 1); actorKind: "human" | "agent" } | |
reason optional | string (min 1, max 5000) |
sweep_research_sourcesCheck papers against their pinned sourcesNone
Compare each published paper baseline with independently verified source releases and local current selections. Return aligned, drift, integrity-failure, or unresolved. Findings change no record, make no claim of scientific correctness, and do not automatically withdraw dependent papers.
| Field | Type | Notes |
|---|---|---|
actor | { actorId: string (min 1); actorKind: "human" | "agent" } |