Skip to main content
A Procedure is a canonical step sequence: the how-to document a team performs by. It owns its steps, and each capture recorded against it either corroborates them or raises a proposal for review. Filing one under a skill is optional, and a guidebook that links a procedure only points at it.

Key fields

Steps

Steps are a sub-resource rather than an array on the procedure. Beyond a title and description, each carries a depth of 0 to 4 for sub-steps, an optional callout (info · caution · warning · danger), a verification describing how the person performing it confirms it is done, and sources and citations recording where it came from. Deleting a step is recoverable.

Proposals

A proposal is a change suggested by a capture rather than by a person, which is how a procedure stays honest about how the work is really done. Each is pending, accepted, or rejected, and one of three kinds: Accepting applies the change to the steps. Rejecting records the decision without changing them.

Revisions

Publishing snapshots the whole step sequence as a numbered, read-only revision, so what someone performed by on a given date stays recoverable after the procedure moves on.

Endpoints

Full endpoint reference is available in the OpenAPI spec. Key operations:
  • GET /procedures: list procedures, filterable by review state
  • POST /procedures: create a procedure
  • GET /procedures/{procedureId}: get a procedure with its steps
  • PATCH /procedures/{procedureId}: update title, description, or filing
  • POST /procedures/{procedureId}/steps: add a step
  • POST /procedures/{procedureId}/steps/reorder: reorder the sequence
  • GET /procedures/{procedureId}/proposals: open proposals awaiting review
  • POST /procedures/{procedureId}/publish: snapshot the current steps as a revision