"Accepted" is a state that requires a person. Somebody has to be the one who says the work is what was asked for. If you have never established who that person is, then acceptance has no referent — and acceptance is exactly where that absence surfaces.
Here is one shape it takes. You finish the deliverable. You send it to the person you have been dealing with for six weeks. They say it looks good, and that they will need to run it past someone. That someone has a calendar you do not control, an opinion you have not heard, and criteria you were never told about.
Nothing has gone wrong yet. But you are now in a queue you did not know existed, and the work is finished, which means you have no leverage left to shape it.
The correction is small and it is entirely front-loaded: record who can accept the work as a property of the engagement, before the engagement is active.
In the engagement template that is a field, acceptance_authority, and it sits alongside the governance details that answer the same family of question — the escalation route, the steering cadence, whether change control is written into the contract.
The template treats it as a precondition rather than a nicety. Before you set status: active, three fields must be filled: acceptance_authority, days_sold and end_date. The reasoning is stated in the template itself, and it is worth quoting because it is the whole argument in one line:
An engagement without a named acceptance authority is an engagement whose deliverables cannot be accepted by anyone, and you will discover that at the end.
"At the end" is the operative part. An unnamed authority costs nothing while the work is in flight. It becomes expensive once, at the moment when everything else is already done.
Naming the authority once is not sufficient on its own, because deliverables get accepted one at a time and by whoever happens to be in the room.
So the deliverable carries an "Accepted by" field, and the rule attached to it is that it must match the acceptance_authority on the engagement.
That match is worth more than it looks. When the two agree, the acceptance is the one you contracted for. When they disagree, you have learned something real — somebody other than the named authority has signed off on your work. That may be perfectly fine. It may also mean the acceptance will not survive contact with the person who actually holds the authority. Either way it is now a visible fact recorded on the deliverable, rather than an assumption you will re-examine only if there is a dispute.
The authority question has a twin, and they fail together.
The deliverable template asks for acceptance criteria, written before the work begins, and stated so that a third party could check them. "Covers all four product lines with a recommendation and a sensitivity range for each" is a criterion. "Is useful" is not.
If you cannot say what accepted means, the deliverable is not scoped, and you are about to do work whose completion is somebody else's opinion.
Put the two together and acceptance stops being a negotiation at the end of the work. A named person checks stated criteria. Both halves were fixed while everyone was still relaxed and nobody had spent anything yet.
Three fields and one habit:
acceptance_authority on the engagement, filled before status goes active.question "who decides" has one place to live.
the room.
None of that requires a plugin, a service or an account. They are fields in a markdown file, which means they are also greppable, diffable and yours.
The engagement and deliverable templates described here are published as a free, MIT-licensed repository:
https://github.com/engagementdesk/obsidian-consulting-components
They are designed for Obsidian, which is free to download and published by its own publisher under that publisher's own terms. The tracker queries that come with them use Dataview, a community plugin, MIT licensed, installed by you from its own author under its own licence — no plugin code is bundled by us. The fields described in this article are plain frontmatter and need no plugin at all.
The acceptance_authority field and the governance table live in templates/engagement.md.
More guides on running client engagements in Obsidian: all guides.
---
Engagement Desk is not affiliated with, endorsed by, or supported by Obsidian or by the author of Dataview. Those are separate products from separate publishers, distributed under their own terms.