Sign-off: circulation, conflict, and the doc everyone actually agreed to

Your team already has the requirements-to-signoff playbook — the worked recipe for drafting the doc, building a circulation tracker, sending it out, logging responses, resolving conflicts, and locking a signed version. This module is the layer above the recipe. It’s where you master the judgment that makes sign-off real instead of theatrical: the sequencing that keeps circulation moving without turning into a nag campaign, the discipline of surfacing a genuine disagreement to the person who owns the call instead of quietly resolving it yourself, and the difference between a document that looks finished and one that every named stakeholder has actually agreed to.

It’s Module 4 of the certifiable Business Analyst track, and it inherits everything upstream of it: the stakeholder map that tells you who has to sign, and the requirements doc that is the artifact under governance. Every earlier module produced a document. This module is where a document becomes a decision — the one Engineering is allowed to start building against.

Why sign-off is where the guardrail holds or quietly breaks

Every earlier stage of the BA process — the stakeholder map, the requirements doc, the gap and options analysis, the business case — produces an artifact that looks authoritative on the page. None of that matters if the artifact was never actually agreed to. Most requirements failures that get blamed on “bad documentation” are not documentation problems at all. They’re sign-off problems: a doc went out, some people replied and some didn’t, the deadline arrived, and build started on a document nobody had actually finished agreeing to.

This is the moment the traceability guardrail either holds or quietly breaks, because it’s the only point in the whole process where the document stops being a draft and becomes a commitment. A requirement that traces to a named stakeholder in the doc but never got a dated, explicit yes from that stakeholder is not signed off — it’s just well-formatted. The gap between “looks agreed” and “is agreed” is invisible on the page and enormous in the outcome: it’s the difference between a feature Engineering builds once and a feature Engineering rebuilds three weeks later because Support insists they never actually approved dropping the fraud check.

A sign-off pipeline that clears this bar produces exactly one thing that matters more than the document itself: a log that says, for every requirement, which named person agreed to it, when, and against which version. Everything else in this module — circulation, chasing, conflict resolution — exists to make that log true rather than assumed.

Running circulation without losing momentum

The playbook gives you the mechanics: build the tracker, send the doc, log responses as they land. Mastery is the sequencing and pacing judgment that keeps a multi-stakeholder review from stalling out in the two most common ways — silence, and reply fatigue from being chased too hard, too soon.

• Circulate to authority first, context second. Send to the stakeholders who carry final sign-off authority on the highest-priority (“must”) requirements before you send to the wider consulted group. If the decision-maker for the requirement most likely to be contentious is going to need two weeks and a follow-up meeting, you want to know that on day one, not on the day before the deadline when everyone else has already replied.
• Tailor what each stakeholder sees, not just who gets the email. A stakeholder reviewing 3 of 40 requirements should see a message scoped to those 3, not the full 40-row doc with an instruction to “check the ones that are yours.” A shorter, scoped ask gets a faster, more careful reply — sending everyone the whole doc is what makes review feel like homework, and homework gets deferred.
• Chase on a fixed cadence, not on your gut feeling that it’s been a while. Three business days of silence earns exactly one short, specific follow-up — not a vague nudge, not an apologetic “just checking in,” but a reminder of what’s being asked and by when. A cadence you stick to consistently reads as process; a chase that only happens when you happen to remember reads as nagging, and inconsistent nagging is what actually damages the relationship.
• A stakeholder who’s stalling on a specific requirement is telling you something. If someone goes quiet specifically on requirement 12 while replying promptly to everything else, that’s not random slowness — it’s very often a soft conflict they haven’t said out loud yet. Treat a selective delay as a signal to ask a direct question about that requirement specifically, not just another round of the generic chase message.
• Track “sent” and “reviewed” as different states, on purpose. A stakeholder who opened the doc and hasn’t replied is in a different state than one who was never sent it, and both are different from one who replied with a genuine sign-off. Collapsing these into a single “waiting” bucket is exactly how a still-open item gets miscounted as handled when the round gets closed.

A circulation round that clears this bar produces a tracker where every stakeholder’s status is current and specific — not “waiting,” but “sent Tuesday, chased Friday, meeting booked Monday” — and where the BA can say, at any point during the window, exactly who owes a response and what’s already been done to get it.

Resolving conflicting stakeholder feedback

The playbook’s instruction is blunt: don’t average two answers, escalate to the named decision-maker. Mastery is actually having the discipline to do that every time, especially when it would be so much easier to just pick the more reasonable-sounding side yourself and move on.

• A conflict is a fact to surface, not a problem to solve. The BA’s job when two stakeholders want different things on the same requirement is to lay out both positions plainly and hand the decision to whoever the stakeholder map says has final authority over that requirement — never to quietly write down the version that seems more sensible. The moment a BA resolves a conflict by judgment call instead of by escalation, the traceability breaks: the doc now says something no single accountable person actually decided.
• Splitting the difference is its own failure mode, distinct from picking a side. “Ship a lightweight version of both” can look like diplomacy, but if neither stakeholder actually asked for the lightweight version, it’s a third option nobody signed off on, invented specifically to avoid the discomfort of making someone choose. A compromise is only valid if the decision-maker chose it as the resolution — not if it’s the BA’s guess at what might please both parties.
• Lay out why each side wants what they want, not just what they want. “Engineering wants X, Support wants Y” is a scheduling problem. “Engineering wants to scope down the fraud-prevention piece because the anti-fraud rules need real production data to tune safely, and shipping an under-tuned version in week one risks false-positives that block legitimate customers; Support wants it live day one because every day without it is a day the exact abuse pattern from the original incident can recur” is a decision a person can actually make well. The reasoning behind each position is what turns an escalation question into something answerable in one sitting instead of a back-and-forth that drags the whole round.
• The decision-maker is named by the stakeholder map, not by seniority or by who shouts loudest. On some requirements the final call sits with a function lead; on cross-cutting ones — like a conflict that touches both Engineering’s build risk and Support’s incident exposure — it may need to go up to whoever owns the initiative overall. Check the map before assuming; guessing wrong means re-running the whole escalation with the actual owner later.
• The resolution gets recorded against the requirement, in the requirements doc itself — not just in a meeting nobody wrote down. A decision that lives only in someone’s memory of a call is a decision that will get re-litigated the next time someone reads the doc cold. The doc’s language changes to reflect exactly what was decided, and the sign-off log entry for that requirement should be traceable to the resolution, not just to a generic “signed off.”

A conflict-resolution pass that clears this bar produces a plain-language summary of both positions, a clearly named decision-maker (not the BA, unless the map genuinely says the BA owns that call), a documented decision with the actual reasoning behind it, and an updated requirement whose wording reflects the decision rather than a diplomatic blur of both original asks.

What “signed off” actually means, operationally

The playbook is explicit that silence never converts into a yes. Mastery is holding that line under real schedule pressure, when it would be so much easier to treat three replies out of four as “basically done.”

• A sign-off is a name, a date, and a version — not a vibe. “Priya seemed fine with it in the meeting” is not a sign-off. “Priya Sharma, signed off on requirements-doc-signed-v1.md, 2026-07-14” is. If you can’t fill in all three fields for a requirement, it isn’t signed off yet, no matter how confident the room felt.
• Verbal agreement still needs a written record. A stakeholder who says yes in a call or a hallway conversation has given useful information, but the sign-off log entry only exists once that agreement is captured in writing — even if it’s just Claude drafting a one-line confirmation email for the stakeholder to reply “confirmed” to. The point isn’t bureaucracy for its own sake; it’s that a verbal yes with no written trail is indistinguishable, six months later, from a yes that was never actually given.
• Partial sign-off is not sign-off, and the round isn’t closed until you can name exactly what’s missing. A doc with 38 of 40 requirements signed is not “basically locked” — it’s a doc with two explicit open items, and those two items get named at the bottom of the locked version, not buried or implied to be fine. A round that ends in “we’re close enough” instead of a real completeness check is exactly the gap that surfaces as a rebuilt feature later.
• The version matters as much as the name and date. A stakeholder who signed off on v1 didn’t sign off on v3, even if v3 only changed one paragraph they weren’t reviewing. Any material change after a signature invalidates that signature for the changed requirement and re-opens it for that stakeholder specifically — the log has to reflect which version each name actually agreed to, not just that they agreed at some point.
• The locked document is the version of record, and it says so on its own first line. “Locked for build” at the top of the file, a sign-off log with every required name attached, and any open items called out explicitly — that combination is what lets Engineering start with confidence instead of a hopeful assumption that everyone upstream is actually aligned.

Your assignment

Run a complete circulation → conflict-resolution → sign-off cycle for one real initiative — your own (recommended: this becomes the actual go-ahead your team builds from) or the sample brand Mizan, the GCC bookkeeping SaaS whose Business Analyst, Noor Al-Suwaidi, runs throughout this track. Open your requirements doc, stakeholder map, and any prior gap or options analysis in Claude Desktop and work in the chat — no terminal needed.

Module 4 deliverable — the sign-off pipeline

Inherits from earlier modules: stakeholder-map.md, requirements-doc.md
(+ any gap-analysis / options-analysis / business-case that already
informed scope)

1. circulation-tracker.md
   - one row per stakeholder: scope, status, authority level, date
     last contacted
   - at least one full pass through "not sent -> sent -> reviewed"
     for every named stakeholder

2. A logged real conflict
   - both positions laid out plainly, with the reasoning behind each
   - the named decision-maker per the stakeholder map (not the BA,
     unless the map says the BA owns that call)
   - the escalation question actually sent, and the decision that
     came back, with reasoning

3. requirements-doc-signed-v1.md
   - "locked for build" stated at the top
   - a sign-off log: every requirement, its stakeholder, sign-off
     date, and version signed against
   - any requirement without a full sign-off called out explicitly
     as a known open item, not silently omitted

PII: strip names/roles you don't have permission to share before any
prompt if you're using a real workplace initiative; the Mizan sample
is safe to use as-is.

How it’s graded — the rubric

This is the part the free playbook doesn’t score you against, and the part that makes the credential mean something. Your deliverable is scored against five criteria. Each is meets / nearly / not yet, and a “nearly” on any one is a revise, not a pass.

Sign-off pipeline rubric

1. Every stakeholder explicitly responded
   Each name in the tracker ends the round as "signed off," "signed
   off with a change," or "not responded" — never assumed from
   silence or inferred from a meeting nobody wrote down.

2. The conflict was resolved by a named decision-maker
   A real disagreement was surfaced plainly (not smoothed over, not
   split down the middle) and handed to whoever the stakeholder map
   names as the authority on that requirement — not silently decided
   by the BA.

3. The decision has real reasoning, not just a verdict
   The escalation and its answer show why each side wanted what they
   wanted and why the decision-maker chose what they chose — "we
   went with Engineering's scope" alone doesn't clear this bar.

4. The sign-off log is real: name, date, version
   Every signed requirement traces to a specific person, a specific
   date, and the specific version of the doc they signed against.

5. Open items are named, not buried
   Anything not fully signed off by the close of the round appears
   explicitly at the bottom of the locked document — never implied
   to be fine, never quietly dropped from the count.

The discipline here is what a skeptical engineering lead would demand before committing a sprint: a doc that claims full sign-off but can’t produce a name and a date for one requirement fails quietly — usually the week build starts, when someone says “wait, who actually agreed to this?” — so it has to be caught here, before Engineering ever opens the file.

The bar, shown — a worked model answer (Mizan)

You don’t have to guess what “meets” looks like. Here’s a passing excerpt for the sample brand — your own doesn’t need to look like this, it needs to clear the same bar. Business Analyst Noor Al-Suwaidi is running sign-off on the “dispute a charge” self-serve feature, commissioned by co-founder Dana Al-Qassimi after the March 1, 2026 double-billing incident, with requirements touching Support, Finance, Data, and Engineering.

circulation-tracker.md — Mizan "dispute a charge" requirements (excerpt)

Stakeholder          Scope (req #s)   Authority        Status
--------------------------------------------------------------------
Layla Al-Nasser      1-6, 14-16       Final (Support)  Signed off (v1, Jul 8)
(CX Lead, Support)

Youssef Hamdan        7-11             Final (Finance)  Signed off (v1, Jul 9)
(Finance Analyst)

Maya Haddad           1-3, 12-13       Consulted (Data) Reviewed, no
(Business Analyst,                                      objection (Jul 8)
Data)

Bilal Al-Mansouri     1-16, all        Final            CONFLICT on
(Engineering)         (Engineering                      req 9 -- see below
                      feasibility)                       (all else signed
                                                          off v1, Jul 10)

Dana Al-Qassimi       All (escalation  Final (initiative Decision issued
(Co-founder)          only)            owner)             on req 9, Jul 11

Logged conflict -- requirement 9, Mizan "dispute a charge" (excerpt)

Requirement 9: "The dispute flow runs an automated fraud-prevention
check before any refund is issued, blocking refund release until the
check clears."

Support's position (Layla Al-Nasser): ship the fraud check in v1, day
one. Reasoning: the March 1 incident already showed customers will
test a self-serve refund path for abuse the moment it exists: every
day the flow ships without a fraud check is a day the exact pattern
that caused the original incident can recur, and Support would be the
team fielding the fallout again.

Engineering's position (Bilal Al-Mansouri): scope the fraud check out
of v1; ship the dispute-and-review flow first, add automated fraud
prevention in v1.1. Reasoning: the fraud rules need real production
dispute data to tune thresholds safely -- an under-tuned check on
day one risks false positives that block legitimate customers from a
refund they're owed, which is a second, different kind of trust
damage from the same incident.

Named decision-maker per stakeholder-map.md: Dana Al-Qassimi owns
cross-functional scope conflicts on this initiative -- neither Layla
nor Bilal has authority over the other's function here.

Escalation question sent to Dana: "Support and Engineering disagree
on whether v1 ships with automated fraud prevention or a manual
review step instead, with automation following in v1.1. Support's
case is incident-recurrence risk; Engineering's case is false-positive
risk from an untuned model. Which do we ship for v1?"

Decision (Dana Al-Qassimi, Jul 11): Ship v1 with a MANUAL review step
for any refund over AED 150, not automated fraud prevention -- and
automated checks land in v1.1 once real dispute volume exists to tune
them. Reasoning: this gets Support's day-one protection (nothing
above AED 150 releases without a human look) without Engineering's
false-positive risk from an undertuned model. Requirement 9 rewritten
to reflect this; both Layla and Bilal re-confirmed against the new
wording on Jul 11.

requirements-doc-signed-v1.md -- sign-off log (excerpt)

LOCKED FOR BUILD -- v1, 2026-07-11

Req #   Stakeholder            Status        Signed          Version
------------------------------------------------------------------------
1-6     Layla Al-Nasser        Signed off    2026-07-08      v1
7-11    Youssef Hamdan         Signed off    2026-07-09      v1
9       Layla Al-Nasser        Re-confirmed  2026-07-11      v1 (post-
                                (per Dana's                   decision)
                                decision)
9       Bilal Al-Mansouri      Re-confirmed  2026-07-11      v1 (post-
                                                               decision)
12-13   Maya Haddad            Reviewed, no  2026-07-08      v1
                                objection
1-16    Bilal Al-Mansouri      Signed off    2026-07-10      v1

Known open items: requirement 15 (native Arabic dispute-reason labels)
awaiting sign-off from the localization reviewer, not yet named in
the stakeholder map -- flagged to Dana for a named owner before v1.1
scoping starts. Not a blocker for this build: requirement 15 is
"should," not "must."

What you’ve proven — and what’s next

Clear the rubric and you’ve proven something the free playbook alone can’t certify: that you can run a multi-stakeholder review to genuine completion, surface a real disagreement instead of quietly resolving it yourself, and produce a document Engineering can build against with confidence instead of hope. That’s the Sign-off stage of “Certified Business Analyst with Claude.”

From here the track moves to the two systems that sit on either side of sign-off in a BA’s actual week:

• Module 5 — the decision layer: the discipline behind gap analysis, options analysis, and the business case that gets a scope decision made before it ever reaches circulation — so what you circulate in Module 4 is already the right thing to sign.
• The exec briefing: compressing a signed-off initiative into the two-minute version a leadership audience needs, without losing the traceability this module just proved.

First, make the sign-off discipline reusable: keep the circulation-tracker and sign-off-log templates as living documents you reuse on every initiative, not artifacts you rebuild from scratch each time — and hold the line on the one rule that makes all of this worth doing: no requirement proceeds to build without a name, a date, and a version attached.