How SignedOffBy works

Choose the vendor, the offering and up to five functional areas, then paste the client's brief. The engine lists every setup task in scope in the vendor's published order and reads the vendor's rules for each one: the inputs it requires, the defaults it applies, the dependencies it checks, and the design rules that block a bad configuration.

It reads named facts from the brief, such as the business unit, ledger and currency, and quotes the words it read them from. Anything the vendor requires that the brief doesn't give becomes an open question for the client. Tasks with no published rules are listed in order, with nothing invented for them.

No model is called at this stage. The plan is sealed the moment it is made.

An assisted pass sends the brief and each task's vendor guidance to a model, one task at a time, on your firm's own Anthropic key. The model proposes values, answers to the open questions, run-book steps, risks and points for a person to decide.

Code, not the model, then checks every quote the model cites against the brief. A value the model says came from the brief, but whose quote isn't there, is marked Quote not found in the brief rather than trusted. A reply that doesn't fit the expected shape gets one retry, and is otherwise discarded and noted.

You set a spend ceiling for each pass. Before every call the service estimates its cost from the size of the request and the most the reply can be, and stops if that would pass the ceiling. It is an estimate; Anthropic's bill is the final figure. When the pass finishes, its proposals are sealed.

Specialists see the proposals for each task grouped by kind, each with its basis label and quote. They sign the task off or return it, with an optional note. The signature line on the pass fills only when every task with proposals is signed off.

By default, the person who started a pass can't sign it off. A workspace owner can allow self-review, and each self-review is marked as such. A reviewer's name and title are captured at the moment they sign, so correcting a name later never rewrites an existing signature.

Every plan and pass carries a fingerprint, sealed into the workspace's audit trail. Each event in that trail is chained to the one before with an HMAC, and the database refuses edits and deletes to sealed records. The verify check recomputes the fingerprint and walks the whole chain, and tells you plainly whether the record is intact.

To show a client, create a share link for the pass. They see the sign-off record with the seal checked at the moment they open it, and nothing else in your workspace. Links expire, can be revoked, and count their views.

The seal shows a record hasn't changed. It doesn't show the content is right: that is what the named sign-off is for.