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.

Points on a bound object

A step points at a bound object through its componentTags, which match the names of the model’s parts. A 3D scan has no named parts, so a binding can also carry landmarks: named points placed on the model’s surface. A landmark’s name is a tag like any other, so a step references it by adding the name to its componentTags. Placing a landmark can link it to a step in the same request. Renaming one renames the tag on every step that uses it. Deleting one through the API leaves those steps’ tags in place, where they no longer resolve; the dashboard’s delete removes them. Each landmark records the object’s bakedTransform when it was placed or moved, as frame. The detail and revision reads serve every landmark in the object’s current frame, so a point placed before a later rotation, scale or recentre of the model still lands on its feature; write responses and list reads serve the stored position with its frame. The detail read also returns objectGeometryChangedAt, the last time the model was rebuilt in a way the recorded transform can’t describe, so a client can flag landmarks placed before it. Publishing freezes the landmarks into the revision.

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}/object-bindings: bind a 3D object
  • POST /procedures/{procedureId}/object-bindings/{objectId}/landmarks: place a point, optionally linking it to a step
  • PATCH /procedures/{procedureId}/object-bindings/{objectId}/landmarks/{landmarkId}: rename or move a point
  • DELETE /procedures/{procedureId}/object-bindings/{objectId}/landmarks/{landmarkId}: remove a point
  • POST /procedures/{procedureId}/publish: snapshot the current steps as a revision