Widen write access only after trust is proven.

Connected is not trusted

The credentials work. The webhook arrives. Someone asks for write access to "finish the integration." The ordinary path will probably work on day one. The expensive path is a write that lands while status still says pending, or a command that fires twice because nobody named what "acknowledged" means.

Trust for an integration is not a feeling about the vendor. It is a ladder of evidence about one write edge: can you read the truth, can you attempt a write without committing, can you commit inside a bound, and only then can you widen. Skipping rungs is how a connection test becomes a production incident with a polite postmortem.

This note is a walk-through of the TWIMCO Integration Trust Ladder Scorecard: one scorecard per write edge, filled before you widen what the integration may change. There is no live scorecard app. Copy the rungs. Score what you can show.

On Spin:Market, TWIMCO built both sides of the command path: application workflows and player software, with commands traveling to devices and playback status and device events traveling back. The public lesson is that control is not complete until status returns and the operator can see whether the room matched the intent. An integration that can write without a matching status story is the same shape of risk—whether the target is a device, a ledger, or a ticket system. That is not a claim about Spin:Market's partner APIs. The case is the standard: own both sides of the command before you treat write access as done.

If the work is really about automating a handoff between systems with clear ownership, start with business process automation. Bring the scorecard, not only the OpenAPI file.

Climb the ladder one rung at a time

Fill one scorecard per write edge. "The CRM integration" is not an edge. "Create fulfillment from paid order" is.

Rung 0 — Identify. Name the write, the system of record, and the role who may widen access later. If nobody owns the widen decision, stop here.

Rung 1 — Read proof. The integration can fetch the fields it will later overwrite or depend on, and a human can reconcile those fields with the UI an operator trusts. Score 0 if read was assumed, 1 if described, 2 if shown against a record you recognize.

Rung 2 — Shadowed write. The integration produces the payload it would send, stores it, and does not commit—or commits to a sink that cannot affect customers. Compare payload to what a careful human would have sent. Score 2 only when mismatches are reviewable and someone reviewed a batch.

Rung 3 — Bounded write. Real writes, narrow scope: one object type, one environment slice, rate limits, idempotency key policy if retries exist, and an explicit blast radius. Score 2 only when a failure was recovered using the runbook you wrote before the bound opened.

Rung 4 — Open write. Wider object types or volume, still with monitoring on status match and a named rollback or compensate owner. Score 2 only when Rungs 1–3 were 2 and a week of bounded operation (or your written equivalent observation window) showed no unresolved mismatch. Do not invent a defect rate. Write what you observed or "window not completed."

Advance rule. You may open the next rung only when the current rung is 2 and the failure owner is named. Conditional means a dated re-score. Fail means any attempt to skip with a "we'll monitor." Monitoring is not a rung. It is how you notice you skipped one.

That field set is the TWIMCO Integration Trust Ladder Scorecard. Another studio can say "start read-only." They do not have your rungs, your shadowed batch, or your bounded recovery evidence.

What "proven" means on each rung

Walk one write edge up the ladder.

Read proof sitting. Open the record in the operator UI and via the integration. Diff the fields the write will touch. If the integration cannot see a field the UI shows, the write will guess. Guessing is not Rung 1.

Shadow sitting. Generate fifty payloads or one honest day's volume—whichever is smaller and still real. Review mismatches. If nobody has time to review, you do not have shadow evidence; you have a folder.

Bound sitting. Turn on writes for the narrow slice. Keep a kill switch owned by a role, not a Slack channel. Force one failure in staging that mirrors production auth and idempotency behavior. Recover it. Write what broke and who fixed it on the scorecard.

Open sitting. Widen only the dimensions you scored: more SKUs, more stores, more event types—one dimension at a time when you can. Re-score status match after each widen. A widen that adds three dimensions at once is a new integration wearing the old name.

Status match is the spine. On a platform like Spin:Market, command without returning status is unfinished control. On a ledger or OMS, write without a readable resulting state is the same unfinished control. Put the status fields on the scorecard beside the write fields. If status can say success while the effect is absent, Rung 3 is not done.

Ways teams skip rungs without noticing

Composites—not Spin:Market incident data and not measured error rates.

Credential theater. OAuth succeeded, so writes were enabled. Rung 1 was never scored against operator truth.

Shadow theater. Payloads were logged and never reviewed. The folder counted as "we shadowed."

Bound that was open. The "pilot" included every store because filtering was hard. Blast radius was marketing copy.

Retry without a key policy. Bounded writes double-applied under timeout. The ladder advanced anyway because the happy path looked fine.

Status optional. The write API returned 200. Downstream state lagged. Operators trusted the 200. Customers trusted the lag.

When you see these, do not add a dashboard tile. Close the rung: evidence, owner, advance rule. The unreproducible asset is your filled TWIMCO Integration Trust Ladder Scorecard—your write edge, your rung scores, your shadowed mismatch notes, and the recovery you actually ran. A checklist that says "test in staging" does not name the rung. Yours does.

Put this into practice

1. Pick one write edge that must not widen on hope. Put it on the TWIMCO Integration Trust Ladder Scorecard.
2. Score Rungs 1–3 with evidence dates. Leave Rung 4 blank until the bound observation window finishes.
3. Name the role who may advance a rung and the role who may pull the kill switch. They can be the same person; they cannot be "the channel."
4. Re-score after every schema or auth change that could change write behavior.
5. If the gap is automating handoffs with inspectable status on both sides, bring the scorecard to business process automation. Borrow the public standard from Spin:Market: commands and status are one trust problem, not two tickets.

A green ping means you can call. It does not mean you should write.