SELECTED ENGINEERING / TOPOLO PLATFORM

From intent to a verified result.

Designing the contract, the authority and the path back from uncertainty.

01 / THE ACTION LIFECYCLE

One action. Four design decisions.

A simplified map of the operating pattern. The published contract below shows a real interface from my platform work.

DiscoverRead the current contract.
BindIdentity. Workspace. Record.
ExecuteRun the permitted action.
VerifyRead the resulting state.

EXAMPLE / PUBLISHED PLATFORM INTERFACE

Start with a readable contract.

An extract from Topolo Web’s published read action. The purpose, input and required permission are visible before execution.

json
{
  "action": "app_topolo_web.sites.get",
  "method": "GET",
  "path": "/api/studio/sites/{siteId}",
  "permission": "studio:read",
  "requiredInput": [
    "siteId"
  ],
  "requestScope": "workspace"
}

02 / THE OPERATING BOUNDARY

Make authority part of the interface.

The request needs an explicit business context, the intended resource and permission to perform the action.

OrganizationWhich business context?
Workspace + recordWhat is the actual target?
PermissionIs this action allowed?

03 / THE UNCERTAIN PATH

Design the return journey.

Success is one state. A dependable operating model also needs a way to explain uncertainty and recover.

The response was lost. Did the action happen?

Treat the result as unknown. Read the existing state and reconcile it with the intended effect before making a second attempt.

Two writers changed the same record.

Concurrent edits need a conditional write as well as a final readback. The interface contract needs to make both responsibilities explicit.

THE PRODUCT DECISION

Make the next step understandable.

The interface includes what the action does, what it needs, what it changes and how the result can be checked. Those details shape whether a person or agent can use the system with confidence.

Building software that can act?

Let’s work through the experience, the operating boundary and the system behind it.