Engineering · Coordination
Handshake
Invite someone into the decision.
01
In plain English
- What it is
- A simple way for a supplier or client to confirm one project decision through a limited link.
- How it works
- You would send a request, such as confirming a delivery date. The recipient sees only the relevant details and replies. If those details change, they must review the new request.
- Why it matters
- To get small decisions made without bringing every external contact into the whole project.
02
The product film
A small decision should be a small ask. A task, a deliberate gesture and its result, inside a reconstructed Signal Studio. It plays on its own while it is on screen; pause it, scrub it, slow it down, or read it as stills.
Scene rendered by preview-handshake.js · 45s · 5 beats · 3 stills
03
What it is worth
One clear yes. One less loose end.
A supplier shouldn’t need to learn your project system just to confirm a delivery. Give them the one decision they need to make, and keep their answer beside the work.
- One focused requestThe date, place and decision are together.
- Just the details they needInvite them into the decision with a limited view.
- An answer the team can findKeep the confirmation with the exact request it covers.
04
How it is built
One external person confirms one fact through a limited link. The gesture crosses a boundary — from a project, to a stranger, and back — and the animation has to make that crossing visible.
cubic-bezier(0.65, 0, 0.35, 1)
- The request is prepared
- 600ms
- It reaches the supplier
- 2000ms
- The answer returns
- 1300ms
The same ticket element appears on both sides of the boundary. It is not redrawn: it is carried, so the viewer can see that the supplier is answering the exact request that was sent.
The return trip is faster than the outbound one. Waiting is the honest part of the model; the answer arriving should feel like a release.
If the request changes, the confirmation is void. That rule lives in the process instrument below, not in the film — a film should not be asked to carry a policy.
05
The working model
The request binds an allowed action to a revision. A response is meaningful only while that exact context remains current.
The boundary that matters Server-side scope controls every read and write. An expiring opaque link grants no general workspace access; required identity checks remain separate.
Two paths: Standard flow and Delivery date changes · 5 stages each
06
How it fits together
A person acts, the system checks, a result follows — and one other path, for when the check does not pass. This describes proposed responsibilities and decisions, not deployed infrastructure.
Read the diagram source
%% Director-friendly architecture. Maturity and limits are recorded in accDescr.
flowchart TB
accTitle: How Project Handshake works
accDescr: A project manager sends one clearly scoped request. An expiring link shows the supplier only that request, with recipient verification when required. The supplier responds. Signal records the answer only while permission, expiry and request details remain valid. A changed or expired request needs a new decision. This is a proposed concept, not an implemented access guarantee.
A(["Project manager<br/>Requests one decision"])
B("Private link<br/>Only this request visible")
C(["Supplier<br/>Reviews and responds"])
D{"Request and access<br/>still valid?"}
E("Decision recorded<br/>For these exact details")
X("Request no longer valid<br/>Ask again")
A --> B
B -->|Verify when required| C
C --> D
D -->|Valid| E
D -->|Changed or expired| X
classDef human fill:#faf7f2,stroke:#bf8c53,color:#24211c;
classDef work fill:#ffffff,stroke:#a3a5ad,color:#25262a;
classDef decision fill:#f3efff,stroke:#967bcb,color:#30244c;
classDef result fill:#f0f6ff,stroke:#7b9dca,color:#1d365b;
classDef exception fill:#fff5ec,stroke:#ce9b63,color:#64431e;
class A,C human;
class B work;
class D decision;
class E result;
class X exception;
07
The case study
Participation can be a narrowly bounded capability instead of a new user account.
The problem
A supplier needs to confirm a delivery date, but inviting them into the entire project creates access decisions, onboarding effort, and unnecessary exposure of internal work.
The insight
Represent the exact action as a permission of its own. A participant can receive enough context to make that decision without receiving the workspace permissions behind it.
The system
A scoped request would bind one allowed action to a specific resource revision. An opaque, expiring capability is stored as a hash. The server checks expiry, revocation, recipient verification where required, and the current resource revision before atomically recording the response.
The rationale
Small external decisions should not require full product adoption. Restricting the action and its visible context makes lightweight participation easier to reason about.
Responsibilities
- Project decision
- One action bound to a specific resource revision.
- Scoped request
- Opaque token, expiry, revocation, and minimal visible context.
- External response
- Recipient verification depends on the action’s sensitivity.
- Atomic validation
- Record the response only while scope and revision remain valid.
The boundary
A request permits one defined action on one revision. Every read and write is scoped server-side; possession of a URL does not confer general project access.
The trade-off
A bearer link is convenient but can be forwarded. Sensitive actions need additional recipient verification, trading a little friction for stronger identity assurance; read-only link previews must never consume the action.
When it fails
The delivery date changes
Invalidate approval of the old revision. Show that the request has changed and require a new decision against the current details.
The same link is submitted twice
Atomically record a single response and return its existing outcome on retry. Do not create two approvals or reverse an earlier answer accidentally.
The request is forwarded
Reveal only the request’s minimal context. For actions requiring a named recipient, require verification before accepting the decision.
Evidence Design proposal · local demonstration uses synthetic data