Client Delivery

Client Delivery is where a professional services firm runs the work it has been engaged to do. It holds the engagement record and everything that hangs off it: the acceptance decision that says the firm may take the work on, the plan and its baselines, the risk register, the deliverables and their sign-offs, the change requests and what they did to the commercial position, the weekly status report, the workplan behind the answer, and the file of evidence that supports the conclusions. It is one module rather than several because those things are only useful together: a status report that disagrees with the risk register is worse than no status report at all.

• A spreadsheet import for the portfolio you already run somewhere else, which shows you every row and what will happen to it before it writes anything, refuses a bad row on its own rather than the file, and creates nothing the second time you import the same file
• An acceptance file that runs the checks a risk tier demands and tells you, in one list, every reason work cannot start yet
• A plan with real dependency types, a critical path, and baselines that can only be moved by an approved change, readable as a work breakdown or as a timeline where the baseline sits under every bar and an arrow joins every pair of rows that are tied together in time
• Change control that moves the approved value, the end date and the baseline together, and never edits the signed contract value
• Cumulative drift measured against the original baseline, so ten small approved changes cannot quietly move an engagement thirty percent
• Weekly status reports whose key risks are selected from the live register, so the report cannot contradict it
• The composer opens on the reporting cycle the firm has configured, weekly, fortnightly, monthly, or none at all, and proposes a period that ends on the day the firm reports. A firm that reports monthly is no longer offered a seven-day period on every report it writes
• A draft can pull its figures again without being thrown away. The refresh re-reads every snapshot and restamps when they were taken, and it changes nothing the author wrote: not the executive summary, not the accomplishments, not the asks, and not one of the seven traffic lights. The only thing it removes is a highlighted risk the register has closed since, which it names, because a report may not point at a risk the register no longer holds open
• Commercials with earned value, burn and margin, and the estimate assumption recorded alongside the number
• A milestone slip chart on the plan tab, drawn from a reading taken of every milestone on every reporting date rather than from the plan as it stands today. It reports how late each milestone is against the date the current baseline froze, and turns red when one has slipped three reporting periods running
• A benchmark register on the structuring tab, where every peer comparison carries the competition-law review it needs before it can reach a client, and says plainly when it does not have one
• A health history on the engagement overview: the composite score as it has actually been recorded, how far it has moved across the window, and each signal with the share of the score it carried, so a fall reads as a reason rather than as a mystery
• The risk register is worked from its own screen on each engagement rather than only read as the eight hottest items on the overview. The facet counts across the top come from the register rather than the rows on screen, because the list is capped and a chip computed from a truncated page reports fewer risks than exist, and a chip reading twelve on a register holding three hundred is worse than no chip. The overdue-review count appears only when something is actually overdue, and choosing a facet re-asks the server rather than filtering the page, so a match sitting past the cap is not hidden
• A risk, an issue or a dependency is scored on a five-by-five grid of probability against impact, twice: once as it stands and once as it will stand after the mitigation. The two are set independently, because comparing before with after is the point of recording both. The heat band is written by Atlas alongside the score and read back onto the row, never worked out in your browser, so the register and every report drawn from it always agree about which risks are red. An assumption and a decision are offered no grid at all: neither has a probability axis, and a heat map built partly from beliefs means nothing
• Closing an item out offers only the endings its kind actually has. An assumption is validated or invalidated, a decision is accepted or rejected, and a risk, an issue or a dependency is resolved or closed. Any of the five can be voided when it was raised in error, which is the honest way to strike a mistaken row rather than closing it as though it had been worked. Every close-out carries a written explanation, because an item closed without one cannot be explained afterwards. Closed items move below the live register rather than disappearing from it
• The register is read three ways from one screen. The list is one. The heat map is the same live items placed on a five-by-five grid, with every one of the twenty-five cells drawn whether or not anything is in it, because an empty severe corner is the reading somebody came for. Beside the grid it states what it cannot show: assumptions and decisions have no probability axis and are never plotted, and risks, issues and dependencies nobody has scored yet are counted separately from those, because one is a gap to close and the other is not missing from anything. Closed items are left off, since a heat map is a picture of what the engagement is carrying now
• Review mode works the review cadence in one sitting rather than one row at a time. It looks forward as well as back, since a register reviewed only once an item is already late is late by definition, and it counts what is overdue apart from what is merely coming up, because a single due number lets a register look busy while nothing has been missed. Nothing is selected for you: a review is a claim that a person looked at the item, and if any item in a batch does not belong to the engagement the whole pass is refused rather than half applied
• A risk becomes visible to the client only when somebody shares it, deliberately, from the register. Sharing and withdrawing are the only two ways an item changes who can see it: no edit accepts the field, so there is no quieter route to the same effect. Both write an audit row and an entry in the event log of the item itself, withdrawing requires a written reason where sharing does not, a confidential item is refused outright, and an item the client can still see cannot be removed until it has been withdrawn first. Every row on the register states in words whether it is internal or shared
• The deliverable register is on its own screen with the review gates as a bar in gate order, so the question a delivery is managed by, which is where the work has piled up, is answered by looking rather than by filtering. Advancing a deliverable names no target gate: the server owns the ladder and reports every blocker at once, because a reviewer told about one blocker, who fixes it and is then told about the next, stops trusting the check
• The information request list is on its own screen for the firm side, not only in the client portal. It splits what is sitting with the client from what is sitting with us, which is the question a mobilisation meeting actually asks, and it shows the reporting period a request covers separately from its due date, because a request for March figures raised in July is not four months late. The counts across the top describe the whole register and are read separately from the table, so narrowing the list cannot move them
• The whole chase loop is worked from that screen. A list is raised in one go by pasting one request per line, or copied out of a playbook with its dates counted from today, and each request is sent to the client, chased, or taken up the escalation ladder the engagement agreed. What comes back is accepted, sent back with a reason, or recorded as partly received with the gap written down, and a request that no longer applies is marked so or withdrawn. Every reason is required at the moment it is still known, and the client reads it in their portal. A request can be removed only before the client has seen it; after that it is withdrawn, so the list never disagrees with the one they answered
• A request can carry several lines, because one request often needs three files across two periods, and each line is marked received on its own. Files already uploaded to the engagement are attached to the request they answer rather than uploaded again through a second route, and the request list is exported as a spreadsheet, a PDF or Markdown with a client edition that carries only what the client can see
• Change control is worked from its own screen, with cumulative drift against the original baseline shown next to the register rather than buried in a report. The individually approved change is the easy case; ten changes each under the approval threshold is the case that costs an engagement its margin. The drift figure informs and does not block, because a counter that blocks is a counter that gets routed around, and the submit control appears only on a draft rather than on everything with the server refusing the rest
• Client acceptance is a screen that answers one question, which is whether work may start, and answers it above the table rather than leaving somebody to derive it from a list of statuses. A waived check does not block, because a waiver is a decision on the record rather than a skipped step. An expired check does block even where its status still reads cleared, because a sanctions screen from two years ago is not a cleared sanctions screen, and an optional check never blocks, because a firm that cannot tell its required checks from its discretionary ones starts waiving the required ones to get moving. The staffing restrictions a check carries, including the nationalities permitted on the team, are shown on the check itself, since the person reading the acceptance file is the person about to staff the engagement
• Status reports are written, reviewed, approved and issued in a composer of their own, and the register that lists them carries no lifecycle controls at all: every decision that moves a report is taken on the screen where the report can be read first. Submit, approve, send back, issue and replace are five separate actions with five separate confirmations, because they are separate decisions taken by different people at different moments, and collapsing them is how a half-checked report reaches a client. Issuing names its audience in the confirmation, since the word issue on its own does not say who is about to receive the document
• The composer proposes the period that has not been reported yet, counted from the day after the last issued report rather than from today, so a report written three days late still covers the week it was meant to cover. Each of the seven traffic lights carries where it stood last period and which way it moved, because a sponsor reads the movement before the value: amber holding steady and green falling to amber are different stories. The lights arrive as suggestions computed from the figures, and a light the author overrules is recorded as an overrule with the suggestion it replaced, so a reader can tell a judgement from a measurement
• Key risks on a report are picked from the live risk register and never typed, so a report physically cannot name a risk the register closed three weeks ago. The picker shows every item with its current status, a closed item cannot be selected, and a highlight the register has closed since the draft was built is flagged on the report itself. A report also says when its figures were taken, and warns once they are more than a week old, because it is otherwise describing a state that has since moved on
• Beside the composer sits the document the client actually receives, rendered from the same ten fields the portal serves rather than from a styled copy of the form. An internal report is banded as internal, and the preview says in words that the client sees nothing, because only an issued report addressed to the client and not marked confidential ever reaches the portal
• Engagement economics shows earned value in full, keeping the standard field names so a delivery lead who knows what CPI means does not have to learn a local vocabulary. Every money figure is rendered exactly as the server computed it, with no arithmetic in the browser, because engagement money is a fixed-point decimal and formatting it through a floating-point number is a rounding error nobody notices until an invoice disagrees with the report that justified it. The estimate at completion names the formula that produced it, since several are in common use and they disagree, and the to-complete index is omitted rather than shown as zero when there is no remaining work to index against
• Threads carry an owner, a response clock and an escalation path, and the screen distinguishes a thread that is waiting on the client from one that is waiting on us. The first reply is recorded separately from the resolution, because a thread answered in an hour and closed three weeks later is fast to respond and slow to resolve, and one timestamp cannot say both
• The stakeholder map groups people by the strategy that applies to them rather than listing them flat, because the grouping is the whole point: a contact list does not tell anyone who to manage closely. Support runs from opposition through to advocacy rather than starting at neutral, since opposition is a real position that a scale beginning at neutral cannot express, and anybody the engagement is overdue a conversation with is marked as such
• The plan is worked from its own screen, either as an indented work breakdown structure or as a timeline, with the critical path and the float computed by the server rather than by the browser. The timeline draws each row as a bar against a day, week, month or quarter axis and puts the frozen baseline finish under the bar as a thin ghost, so a slip is a length rather than a subtraction somebody has to do in their head once per row. It also draws the dependencies: an arrow runs between every pair of rows that are tied together in time, a hard dependency that the schedule is built on is drawn as a solid line with a filled head while a soft one is dashed with a hollow head, and a lead, which is a negative lag that lets two rows overlap, reaches backwards and is marked as such. An arrow whose row at either end is folded away, filtered out, or undated is not drawn at all, and the number of arrows in that state is stated under the chart rather than left as silence. It is a read-only view: dragging a bar would write a date without the forward and backward pass the server runs, and the plan would then disagree with the float beside it. Both views band the plan by phase and then by workstream, using the names in the phase and workstream registers, and both read one row model, so the bands, the order and the indentation can never differ, and the choice between the two views is remembered. Work that has not been placed in a phase, or in a workstream, is gathered into a band of its own at the end and named as such rather than folded into the first one. Float is shown as absent rather than as zero where an item has no dates, because zero float reads as being on the critical path and that is a different claim. Every percentage carries the source it came from, since a number whose provenance is unknown can be neither argued with nor corrected. Narrowing to the critical path asks the server, because the plan is capped and filtering in the browser would hide exactly the critical rows somebody switched the filter on to find
• Workstreams are on their own screen with the traffic light as the point of it, and a workstream showing amber or red without a written reason is flagged as such. A light that says something is wrong while nobody recorded what is the most common way a status report stops being trusted, and it is the one thing this screen refuses to let pass quietly. A light that has not been assessed reads as not assessed rather than as a quiet green
• Meeting governance is on its own screen, where quorum is reported in three states rather than two: not evaluated, met, and not met. Collapsing the first into the last would report every meeting held under a policy that requires no quorum as inquorate, which is a governance claim nobody made. Minutes approved with a content hash are shown as sealed, because an approval over content that can still change proves nothing, and a disputed record is shown as disputed rather than hidden, since a system that cannot express disagreement simply moves the disagreement off the record
• Each meeting opens at its own address, so a link to it can be sent. One page carries the whole occurrence rather than five tabs, because the agenda, the notes, the minutes, the approval and the actions are maturities of one document and tabs would let somebody publish minutes that do not match the agenda they ran. A stage rail across the top shows how far the meeting and its record have got, and exactly one action is offered at each stage: start it, record it as held, circulate the minutes, approve them, or publish a new version. The agenda is reordered whole rather than a pair at a time, so two people rearranging it at once produce an order one of them can see is wrong instead of an interleaving neither of them chose. Attendance is one tap per person, and taking somebody off the list recomputes quorum, since removing a voting member changes both sides of that arithmetic
• Minutes now have a lifecycle rather than a status field. They are written, circulated to a named approver with a deadline taken from the forum, and then approved, sent back with a reason, or disputed. Approval requires circulation: approving a set of minutes nobody was sent would seal and hash a document that had never been shown to anybody. Circulating requires an approver, because a clock with nobody on the other end produces an overdue flag against a person who was never asked. Editing circulated minutes drops them back to draft and the circulation has to happen again, since an approval clock running against text that has since changed is worse than no clock. Each circulation opens a numbered approval round, and the rounds are listed oldest first, so a rejection followed by a second circulation reads as the sequence it was
• While a meeting is being minuted, Command Shift and D, A or R records a decision, an action or a risk without leaving the page. Each becomes a real item on the register that owns it, linked to the agenda item it came from, and leaves a marked line in the body of the minutes so somebody reading the record end to end sees the decision where it was taken. Four things reach the engagement timeline from here and no more: minutes circulated, approved, sent back, and disputed. Saving a draft reaches nothing, because drafting is the secretary talking to themselves
• Every meeting in a recurring forum shows what the previous occurrence left open: the agenda items nobody got to and the actions still owed. A meeting that belongs to no series says so plainly rather than showing an empty list, and so does the first meeting of a series, because neither is the same as the last meeting having finished everything. An item that was not taken is carried forward from the agenda itself, with the reason it was not taken, and the next chair reads that reason on the agenda rather than in an audit log
• The governance forums sit above the register: a forum is the standing body and each meeting is one sitting of it. Scheduling a sitting from its forum is what carries the chair, the quorum rule, the room and the duration onto it, so a steering committee cannot quietly be created without the quorum rule that makes its decisions valid. Asking what a cadence would produce writes nothing at all and marks the dates the register already holds, so nobody is offered a duplicate the server would then refuse. A forum can be stood down, which stops it producing sittings and keeps every one it has already held readable, and that is deliberately a different control from deleting it: deleting is refused while any sitting remains, because a set of approved minutes describing a committee the register can no longer name has lost the thing it was a record of. Each forum carries its terms of reference, which is the document a chair points at when somebody brings a decision to the wrong body
• A governed meeting can be tied to the calendar meeting it was actually held as, and the notes of that call pulled onto the minutes as a first draft. The two are separate records on purpose: the governance record carries the chair, the quorum rule and minutes that are sealed when approved, and it has to outlive a calendar entry somebody deletes. What is pulled in is a draft and never more than that, because a machine has not held a meeting and its summary is not the record until a person has read it and said so. Minutes that have already been circulated, approved, sent back or disputed are refused whatever is asked, since they are the version somebody else is reading, and a draft the secretary typed is replaced only on a second, explicit press. The import reports what it actually wrote, the number of decisions and actions it found, rather than reporting that it worked
• A member who cannot attend sends somebody in their place, and the substitute takes the seat with the member role and voting right rather than a new one chosen on the form, so a delegation cannot grant a vote the member did not have. The member is recorded as having delegated, quorum is taken again because the room changed, and a delegate may not send a delegate of their own: a chain leaves a voting right that traces back to nobody
• Once minutes have been approved and republished as a new version, the screen says which lines moved. The approved text stays sealed with its hash while the working copy moves on, and the comparison is line by line with an edit shown as the line that went and the line that came, because saying only that a line changed hides what it changed from, which is the half of the answer a dispute turns on. Where the record is longer than the comparison reads, it says so rather than reporting no further changes
• The register can be read as a month rather than as a list, showing only what is scheduled inside it. A meeting nobody has placed in the calendar is left out rather than drawn on the first day, because it is not at any point in a calendar. A meeting can also be taken off the register while its minutes have never left the drafter; the moment they have been circulated or approved it is cancelled instead, which keeps the record and says it did not go ahead
• The hypothesis tree is worked from its own screen, ordered by a materialised path compared segment by segment so that branch 1.10 follows branch 1.2 rather than preceding it, which a plain text sort would silently get wrong and quietly reorder the argument. Whether a set of branches is mutually exclusive and collectively exhaustive is reported in three states, because nobody having checked is different from having checked and found a gap. A hypothesis marked supported without a written conclusion is flagged, since claiming support without recording what supports it is the exact failure a hypothesis tree exists to prevent
• A working paper file on its own tab, promoted on an assurance engagement and reachable on any other. It carries the assembly standard, the archival deadline, and every paper with its preparer and its reviewer, and it becomes append-only once it is locked, with every later addition recorded and approved
• Exports for every register, in spreadsheet, document and PDF form, with a separate client edition where one is appropriate. Sixteen of the twenty-eight artifacts the module plans are built today, and the export menu offers exactly those: an artifact nobody can produce is never listed, so a row you can choose is a document you will receive
• A meeting minutes pack that gathers the run of minutes into one document rather than one meeting at a time, because the decisions in a governance record reference each other. Each meeting carries its own header, attendance, agenda and outcomes, decisions taken, votes with the tally, the actions it raised, and the approval rounds the minutes went through with the hash of exactly what was approved. A quorum nobody evaluated is reported as not evaluated rather than as not met, because which of the two it was decides whether the decisions taken in that meeting stand. The client edition carries only approved minutes of meetings marked for the client and not marked confidential
• A deliverable acceptance certificate, which is the artifact an auditor asks for. It names the deliverable, its version history with the hash of what was issued, every acceptance criterion with the evidence and who assessed it, the review rounds, and the signature. A criterion nobody assessed is reported as not assessed rather than as failed. It certifies acceptance only where an acceptance is actually recorded against the deliverable, and otherwise says in plain words that there is none, because a certificate worded like an acceptance over a draft is worse than no certificate. It is downloaded from the export menu, which asks which deliverable it is about, and from the deliverable itself
• Firm-wide rollups for every engagement in one view: portfolio, RAID, meetings, information requests, actions, approvals in flight and recent exports
• A metric catalogue for each engagement covering delivery, quality, commercial, governance and client measures, with lock-up (the days of revenue held as unbilled work and unpaid invoices) reported alongside the work in progress and debtor days it is made of. The engagement overview reads the part of it that this operating model is judged on, and a measure that could not be taken says so rather than reporting itself as zero
• An engagement health score from zero to a hundred that shows the weight each signal carried, so a partner can see why it moved. A measure nobody has taken redistributes its weight instead of scoring zero, which is why a new engagement does not open in the red. The score is recomputed every hour and stored with the moment it was computed, so the portfolio rating can call an engagement red on its health even when every one of its three lights is green. Available through the API and not yet through a screen
• Engagements, RAID items, deliverables, threads, information requests and the time booked to an engagement are available as reporting datasets, so a custom report, a dashboard widget or a spreadsheet export can be built over them without leaving the report builder. The time dataset counts only timesheet rows that name an engagement, reports effort and never the note somebody typed against it, and honours an information barrier raised over either engagement records or time entries
• Each engagement carries the fields your own firm keeps on one, on a Custom fields tab: a client matter number, a panel code, an internal risk grade, whatever your taxonomy is. An administrator defines them once for the whole workspace in Settings, under Labels and custom fields, with Engagements selected, and they then appear on every engagement. They are the same field definitions the rest of Atlas uses, so a field defined here behaves the way a task or project field does
• An automation can now act on an engagement rather than only watch one. A rule triggered by any engagement event can set any of the seven delivery traffic lights on the engagement that event names, so a risk scored critical can flag the engagement red without anybody opening it
• A built-in playbook catalogue that seeds a new engagement with a phase structure, workstreams, deliverables and a meeting cadence
• A closure-readiness screen that lists every blocker and warning at once, backed by a twenty-item checklist that is a real state machine: three items are derived from live data (open access, open information requests, unaccepted deliverables) and refuse to be ticked by hand, and any item can be waived only by an approver who does not own it, with a reason on the record
• The closure checklist is worked from the closure screen itself rather than through the API alone: the checklist is created on first use, and each item can be completed, waived with a written reason, or reopened, with the readiness summary above it recalculating as the list changes
• Asset harvesting with a two-part gate: a reusable asset stays locked until it has been sanitised and, where the engagement requires it, covered by recorded client consent, so a client confidential model cannot be carried onto a competitor engagement
• The asset register is on its own screen, and it names which half of that gate is still open rather than only reporting that the asset is not reusable. No reuse control appears at all while either half is outstanding, because a button beside a client confidential model that the server would refuse invites somebody to read the refusal as a glitch
• Benefits realisation tracked past the end of the engagement, with dated readings and an attribution guard that refuses a partial claim unless it records where the rest of the benefit is claimed
• The benefits register is on its own screen, and the attribution warning sits on the benefit itself rather than only appearing when it was entered, because the person who has to chase a partial claim is rarely the person who made it. A benefit with no reading says so instead of showing a zero, since never measured is not the same as measured at nothing
• Staffing requests that carry the whole trail from ask to appointment: what was requested, who was proposed, who was confirmed and why anybody was declined, with a contractual gate that will not confirm a key-personnel role until the client approval the contract asks for is on the record
• Staffing and the handover plan share one screen, because they are the same question at two moments: who is on this engagement, and who takes it on when we leave. Where a client approval is outstanding the screen offers no confirm control at all and names the approval that has to happen first, rather than letting somebody press a button the contract forbids
• A transition plan for the handover to run, BAU or a managed service, with hypercare and warranty windows, knowledge-transfer sessions, residual risks and the open-defect count the receiving team is inheriting
• Everywhere a delivery record names a person, that person is picked from the workspace directory by name rather than typed as an identifier, and a person already on the record reads back as their name. This covers appointing a quality reviewer, the partner and the appointer, recording who was crossed through an information barrier and who authorised it, adding somebody to the insider list, proposing somebody for a staffing request, and naming everybody a barrier walls off
• The registers name people too, not only the forms that create them: who a barrier excludes and who may cross it, who was let through a wall and on whose authority, who is on the insider list, who is proposed and confirmed on a staffing request, who declared their independence, and who is approaching a rotation deadline. That last one is the reason it matters: the register exists so somebody can start arranging succession two years out, and a column of identifiers tells nobody who to talk to
• Partner rotation limits held as reviewable data rather than code, covering the SEC and PCAOB, EU Regulation 537/2014, the UK FRC Ethical Standard and IESBA, with a warning two years before a deadline because succession on a large audit takes that long to arrange
• The rotation register and the independence declarations are on the closure screen rather than reachable only through the API, which matters most for the two-year rotation warning: an alert nobody can see is not an alert. Each person is shown against their limit in three states, within it, approaching the deadline, or required to rotate off, with the year they may serve again
• People are added to the rotation register from that same screen, choosing the rule from the published table rather than typing a regulatory identifier. Until a person is recorded against a rule there is no limit to measure them against, so the register stays empty and no deadline warning can be raised
• An engagement quality review that cannot complete while any matter is unresolved, and cannot complete on or after the report date, so a review that did not actually review the report is impossible rather than merely discouraged
• A report-dating readiness check that lists every reason the report cannot be signed yet: an incomplete quality review, unresolved review matters, and any difference of opinion still open, each of which can be started and settled from that screen rather than only read there
• Report dating is worked from the closure screen rather than read through the API: the verdict sits above the two records that produce it, so the quality review can be completed and a difference of opinion can be resolved from the same place that says they are blocking, with a written resolution required before a difference can be closed
• A non-audit service register that computes the EU three-year seventy percent fee cap as a breach and the IESBA fifteen percent dependency level as a flag, because one is a limit and the other needs a safeguard
• The register is on the closure screen with the fee-cap position above it and a form to add to it, and every entry carries what it is still missing: a service recorded without its audit-committee pre-approval reference says so on every reading, not only on the day it was entered
• Information barriers that actually deny rather than merely label: an excluded party is refused even holding a live, unexpired, correctly scoped grant. The refusal is enforced on the portal grant check, on signed downloads, and on the engagement register in every direction: the walled-off engagement is filtered out of the list in the query, reads as not found on a direct address, cannot be changed, archived, restored, rated or deleted, and is refused by every surface that hangs off it. An engagement marked as restricted access is treated the same way and by the same check: without a live access grant it is absent from the list, from your own engagements and from the portfolio count, and it cannot be opened or edited by anybody, including the partner named on it, until somebody grants them access, so its commercials, deliverables, risk register, meetings, working papers, status reports and exports are all closed to an excluded party rather than only its front page
• Wall crossings that are append-only and cannot be self-approved, so the record of who was let through a barrier, when, and on whose authority survives the engagement, and that can be closed from the same screen that opened them: a crossing nobody closes leaves somebody permanently through the wall
• A barriers screen on each engagement where a barrier is raised, wall crossings are recorded, and the insider list is read with its outstanding obligations. A barrier that excludes nobody cannot be created, because it would sit on the register reading as protection while refusing nobody. A barrier naming only enforcement points that are recorded rather than enforced says so on its face, because a partner relying on it would otherwise be relying on nothing
• Deal code names decided by the server from who is signed in, so somebody outside the wall is told the code name and somebody inside is told the real one, with no way for a request to claim it is somebody else. The rule is enforced at the endpoint; the screens that display deal and party names do not route them through it yet, so a code name hides nothing on screen today
• A sanctions screening register on each engagement that records what was actually searched: which lists, at which edition, through which provider. A pass recorded against no list is refused, because a clean result against nothing is not a clean result, and a name cleared eighteen months ago against a list that has moved on is not cleared today
• Every hit has to be dispositioned with a written reason, and a true match needs a second person who is not the one who called it. Approval and disposition are separate actions on separate routes, because four eyes is the control and a single request that did both would satisfy it with one pair
• Beneficial ownership recorded behind the client entity, with the fifty percent rule computed by the server rather than added up on screen: an entity half or more owned by blocked persons is itself blocked whatever the lists say about its name, and the screen banners that verdict above everything else. Where nobody reaches twenty five percent and no senior managing official has been named, the screen says so, and an owner nobody has screened makes the total read as a floor rather than an answer
• A tipping-off lock on suspicious activity. Only the money laundering reporting officers the firm has appointed can see or file a report, and it is the one thing in the module that a workspace administrator role does not buy. Everybody else, the engagement partner included, is served a check that reads as still running, with its completion date, its result and the person who cleared it all absent, so a check with a report on it is indistinguishable from one that is genuinely in progress
• The lock holds on every surface that returns a check, including the acceptance export, which is the file that leaves the product and gets forwarded by email. Readiness is computed from what the reader may see rather than from the underlying rows, because a check list saying in progress beside a readiness verdict of ready would say exactly what the lock exists to conceal
• Source of funds and source of wealth are two fields rather than one. They are routinely conflated, and a file that conflates them is deficient enhanced due diligence: a salary paying an invoice says nothing about how the fortune behind it was made
• The compliance terms an acceptance check is run under are set from the screening screen: where the money comes from, and who may be staffed on the work. Changing them sends only what actually changed, because clearing a field nobody mentioned would turn an edit of a licence number into the removal of a nationality restriction, and a hard staffing filter would go quiet without anybody touching it
• Export control as a hard filter on staffing rather than a note on a file. Where an engagement records a nationality restriction, a US person requirement or an export licence, proposing or confirming somebody who does not satisfy it is refused, and refused again at confirmation rather than trusted from the proposal, because the restriction can be recorded after somebody was put forward and confirmation is the moment they actually join
• The filter refuses what it cannot verify. Somebody with no employee record, no recorded nationality, or no established US person status is refused rather than allowed through, and an expired licence refuses everybody whatever their status. That is the opposite of how most gates behave, and it is deliberate: giving a non-US person access to controlled technology inside the United States is itself an export, and the penalty is criminal rather than commercial
• A client voice screen on each engagement holding two registers: the feedback the firm asked for and the complaints the client raised. A survey sent and never answered stays visible, because silence about an engagement is a fact about the relationship rather than an absence of one
• A bad score obliges a call. The promoter, passive or detractor band is worked out from the score and the scale in use rather than being chosen by whoever types it in, and a detractor is marked as owing a call automatically, so the screen can say how many responses are still waiting for somebody to pick up the phone
• A complaint is handled formally: it carries a reference that can be quoted in correspondence, it has to be acknowledged before it can be resolved, resolving it needs a written summary, and closing it needs both the root cause and what will stop it happening again
• Starting an engagement from a playbook copies in whichever version this workspace actually has: its own edited copy where there is one, the built-in otherwise, and one it wrote from nothing just the same. The phases in their stated order, the workstreams, the deliverables with each one linked to its workstream and carrying what a client accepts it against, the risks and assumptions worth starting from, the meeting cadence, the information requests, the closure checklist, and the acceptance checks with an acceptance file opened for them if the engagement has none. It happens once: a second copy would duplicate all of it, and it is refused on an engagement that already has work on it rather than interleaving a playbook with something somebody built by hand
• A client-facing deliverable copied from a playbook arrives marked for the client audience, visible to them, and contractual; an internal draft or a working paper arrives internal and non-contractual. That distinction is what the acceptance gate and the portal both read, so it is set at the moment of the copy rather than left for somebody to correct afterwards
• The copy is a copy, not a link. Nothing written into the engagement points back at the catalogue, so editing a playbook afterwards cannot reach into an engagement that already started. Nine of the ten collections are copied at that moment. The tenth is the status report sections, which belong to a report rather than to an engagement, so they are seeded instead the first time a report is drawn, which is why the engagement records which playbook shaped it
• A playbook a workspace owns can be edited, and every edit is held to the rules the built-in catalogue is held to. Two people Accountable for the same thing, a deliverable pointing at a workstream that is not there, a deliverable with nothing to accept it against, a check the acceptance file cannot run: each is refused at the moment of writing rather than discovered when an engagement is started from it, and the refusal lists every reason at once so a playbook is fixed in one pass rather than one round trip per mistake
• All ten collections of an owned playbook are editable on the detail screen, one at a time. Each section offers to open, and the editor that opens replaces the list rather than sitting beside it, because two renderings of the same rows disagree the moment one is edited. A field the editor has no control for is carried through untouched, so renaming a subject never quietly deletes who owns the work. A refused write leaves the editor open with the reasons the server gave above it, because those reasons are the list of corrections to make and closing the editor would discard the edit somebody has to fix
• An area with nobody against it says which role the playbook names for it and who holds that role now, in the same place, so the empty seat and the thing that fills it are not in two different parts of the screen. The control that fills them says how many it would fill before it is pressed, and is offered only when it would do something. Areas can also be renamed and moved: the label is what a person reads and the key is what everything else refers to it by, so only the label changes
• A seat the playbook meant to fill can be filled once somebody actually holds the role, from a control on the register rather than automatically: adding a person to a team must not quietly make them accountable for something. It is safe to press twice, it says how many it filled and which roles still nobody holds, and it never overrules an accountable somebody chose by hand, naming the areas it left alone instead
• The matrix rules are shown where the matrix is, so a subject with two Accountables, none, or a client party in the Accountable seat says so on the area it is wrong about. A finding never blocks a save, because a matrix mid-edit is legitimately invalid: somebody removes an Accountable in order to reassign it, and refusing that write is how a responsibility matrix ends up maintained in a spreadsheet instead. Blocking findings are marked apart from advisory ones, because four gates elsewhere refuse to proceed while a blocking one stands
• Who is accountable for what has its own screen on the engagement, listing every area of responsibility with the people against it and the letter each holds, spelled out rather than left as a letter. An area with nobody against it says so, because that is what a playbook applied to an engagement nobody has staffed produces and silence there reads as covered when it means the opposite. A seat can be filled from the people already on the engagement, taken back, and an area added for work the playbook did not name
• The accountability matrix is copied as areas of responsibility, each with its own row: delivery as scoped, quality review before anything reaches the client, the fee and the commercial position. A playbook names role slots rather than people, so each is resolved against whoever holds that role on the engagement. A role nobody holds yet is left unassigned rather than given to somebody who did not agree to the work, and the empty seats are named at the moment the playbook is applied, where they are easiest to fill
• A status report is drawn with the sections the playbook says work of this kind has to cover, in the order it stated. Titles rather than bodies: the guidance on a playbook section tells the author what to write, and putting it into the body would publish the instructions to the client. An engagement started before the library existed, or from a playbook since deleted, still produces a report, with no sections
• A workspace can write a playbook from nothing rather than starting from one of the ten built-ins. It arrives empty and is filled in afterwards, because seeding it with a guessed phase list would be inventing a method on the firm behalf. A short name is chosen for it, which is what the address of the playbook and every link to it use, and it cannot be one a built-in already holds: that is what customising is for
• Three states, one action each, because they are three different outcomes. A built-in is customised, which takes a copy. A copy is reset, which drops the copy and restores the built-in. A playbook the workspace wrote is deleted, which is asked about first and cannot be undone. Engagements already started are untouched by any of them, because each one took its own copy at the moment it started
• A workspace can make a playbook its own. Built-ins are shared by every workspace, so customising takes a copy of the whole playbook rather than patching the shared one: a later change to the built-in cannot then alter what a workspace has already edited, and resetting drops the copy and restores the built-in exactly, with no merge to reason about. Which of the two is offered depends on whether the copy exists, so the screen never presents an edit that would silently change the playbook for everybody
• A playbook library covering ten service lines: strategy advisory, technology implementation, managed service, internal audit, regulatory remediation, due diligence, transformation programme office, advisory retainer, staff augmentation, and training. Each one carries the whole shape of that kind of work rather than a phase list: the phases and workstreams, the deliverables with what a client accepts them against, who is accountable for what, the risks and assumptions worth starting from, the meeting cadence, what has to be asked of the client and by when, the acceptance checks that must clear before work begins, the status report sections, and the closure checklist
• Opening a playbook shows all of it. The library card summarises with counts, and the decision to start an engagement from a playbook turns on the parts a count cannot carry, so the detail screen shows the acceptance criteria, the accountability and the checks in full. Each playbook names exactly one Accountable per subject and never a client party in that seat, because the firm cannot delegate its own accountability to the client it is advising, and a playbook that seeded two would put every engagement started from it into breach on day one
• The two registers sit on their own tab, with the placeholder warning above both: a premise recorded on a placeholder basis is called out where somebody scanning the screen will see it, rather than only on the row it belongs to. The screen also says where the third class lives, so nobody hunts the RAID register for an assumption that is not there
• Three assumption classes rather than one. A delivery assumption is the manager’s, reviewed weekly, and becomes a risk. An analytical assumption is the analyst’s, revisited per analysis run, and when it breaks the model is re-run and a signed answer may have to be restated. A pricing assumption is the partner’s, revisited at each change request, and when it breaks the firm either claims the difference or absorbs it. Collapsing them into one RAID kind loses the owner, the cadence and the consequence
• A placeholder number cannot reach a client. An analytical premise recorded on a PLACEHOLDER basis is how an analyst works while waiting for the real figure, and it is refused outright on a deliverable and blocks acceptance wherever one is disclosed. It is the single most dangerous input to ship, because on the page it looks like every other number
• The two fields the consequences hang on are set on the screen rather than only through the interface: which deliverable a premise was disclosed on, chosen from the deliverables already on the engagement rather than typed as an identifier, and the day it expires. A premise recorded on a placeholder basis cannot be pointed at a deliverable at all, because the server refuses that combination and a control certain to be refused is a worse answer than one that is closed
• A sales to delivery handoff on its own tab, holding what the sale actually promised. It is the gate out of the pipeline: accepting it is what seeds the pricing premises, the risks already known from the pursuit, the team shape as sold, and the promises made in the room, so that what was said during the sale becomes rows the delivery team will read rather than a document nobody opens
• The verbal commitments are the point of the record, and the screen says so. A promise made during the sale and never written down is what a delivery failure traces back to, so their absence is called out above everything else rather than listed among the other gaps, and a completeness score derived from the record weighs them above any other single field. Accepting happens once and reports what it created, because a seed that runs silently is indistinguishable from one that did not run
• A recorded premise can be corrected: its basis, the deliverable it is disclosed on, and its expiry. The asymmetry around a placeholder is the point. Admitting that a number already in front of a client rests on nothing is allowed and recorded, because refusing the correction would leave the register claiming the number is sourced when it is not, and the sign-off gate is where that gets caught. Pointing an unsourced number at a deliverable is refused, because that is the act the rule is about. What a premise says is not editable at all: changing the statement is recording a different premise, and the row is what an issued answer was built on
• A premise under an issued deliverable that goes stale raises a chase rather than sitting silently. The narrowing is the point: an expired assumption nobody has shown a client is housekeeping, and the same one disclosed on a deliverable is a restatement conversation
• A pricing assumption keeps what was sold alongside what is happening, because the change request conversation is exactly the gap between them. Recording the breach needs the account of what actually changed, since a breach flag with no account is an assertion rather than evidence
• A commercial terms register beside the obligations: what the contract says, as fields rather than prose. The liability cap and its period, the uncapped heads, the service levels and their credits, the key personnel clause, the acceptance clause, exit assistance, benchmarking and the rest, each queryable rather than buried on page forty. A delivery lead who has to ask legal what the cap is will not ask, and will find out when it matters
• One term per type, because a contract has one liability cap and a second row would make what does the contract say ambiguous at the moment somebody needs a straight answer. Recording a type again states the position now; that it changed lives on the audit record
• The acceptance term does something rather than merely being readable: where the contract grants deemed acceptance and names a period, that period becomes the deemed-acceptance clock on every deliverable sign-off, instead of a number somebody has to remember. Where the contract grants no deemed acceptance there is no clock at all, because silence is not consent and inventing one would accept a deliverable the client never saw
• A contract obligation register that pulls the binding clauses out of the signed instrument and gives each one an owner, a due pattern and a date, so a reporting or notification clause is something somebody is chasing rather than something buried on page forty of a PDF. A due panel shows what falls inside the next thirty days together with anything already overdue, because a forward-only window hides exactly the clauses that need acting on today
• A clause that names the evidence it demands cannot be marked met without an attachment recorded against it, so satisfying a contractual obligation is a document rather than somebody saying it was done, and waiving one requires the reason to be written down and kept on the audit record
• Follow-ups on anything the engagement is waiting on: a sign-off nobody has given, a RAID register nobody has reviewed, an information request the client has sat on. Each one names who owes it and when Atlas will chase, and the chase date is separate from the due date, so a deliverable due Friday with two days of warning is chased on Wednesday rather than on the day it is already late
• A follow-ups screen on each engagement with three lists, because they answer three different questions: what you personally owe, what is about to fire in the next fortnight including anything already overdue, and everything outstanding. Marking a follow-up as seen is offered separately from completing it and says so, because a chase that stopped when somebody clicked it would be a snooze pretending to be progress
• Every delivery attempt is recorded before it is sent, so a follow-up that reaches somebody twice is impossible rather than merely unlikely, and the record of what was sent and when survives independently of the mail server
• Follow-ups raise themselves. Sixteen rules watch the engagement and create a chase when something is coming due: a RAID item needing review, an assumption about to expire, a deliverable five days from its internal date, a sign-off about to lapse, a meeting with no preparation, minutes nobody has written, an acceptance check whose clearance is running out, a legal instrument expiring, a closure item, a benefit review, a stakeholder nobody has contacted. Each names whoever owns the underlying record, falling back to the engagement manager, and each raises one chase however many times the rules run
• The follow-up rules are set from Client Delivery settings, where each one shows the sentence it will actually send, whether it has been changed from the Atlas default, and a way back to that default. An engagement can differ from the firm on its own follow-ups screen, and only the difference is stored, so a rule left alone there follows whatever the firm decides later
• Each rule can be turned off or given a different amount of warning, for the whole firm or for one engagement on its own. A hypercare engagement can chase harder than the firm normally does without changing what the firm normally does, and a firm that does not work the way a rule assumes can stop that rule without losing the other fifteen
• A commercial term with a date chases itself. Most of the sixteen carry none, so the rule fires only where a date was recorded: a benchmarking review, an exit-plan deadline, a notice window. It names the term type rather than the clause reference, because a clause number means nothing on a list of chases
• One rule is a security control rather than a reminder and behaves like one: access still live on a closed engagement is chased every day until somebody revokes it, and it never stops on its own
• Follow-ups are chased automatically. Atlas checks every few minutes for anything due, notifies whoever owes it, and chases again the next day until the follow-up is completed or cancelled. Where a follow-up sets a limit on how many times it may go unanswered, reaching that limit escalates it to whoever was named and stops the chase, because repeating into an inbox somebody is already ignoring is noise rather than a control
• An insider list under MAR Article 18 with the access timestamp, the obligations notification and the separate acknowledgement, retained five years from the date access ceases
• A client portal at /portal with its own shell: no sidebar, no workspace switcher, no command palette, and the firm brand rather than the Atlas one. The address a client is given is /portal itself, which lists the engagements they hold a seat on and takes them straight through when there is only one. It is not the internal application with rows filtered out, because a client who can see the shape of the internal product can also see how much of it is being withheld. The engagement name and a tab rail sit above every surface, and each surface is its own address: an overview that summarises the rest, the actions assigned to that person, the milestones and how far each has progressed, what the firm needs from the client, the deliverables, the document library, the meetings, the threads, the status reports the firm has issued, change requests, who is on the engagement from both sides, the commercial summary where the firm shares it, and the notification switches. A client asked for two files no longer scrolls past every deliverable and every meeting to find them, and an email can link to the exact surface it is about
• What a client may do is a short list of named actions rather than a general permission: submit an information request, mark one not applicable with a written reason, upload a file against a request item, send a document nobody asked for, download a document the firm has shared, sign off a deliverable that is in client review, read and reply to an open thread, mark an action complete, approve minutes, choose which notifications they receive, and record a decision on a change request. Each one is its own route. There is no general update anywhere in the portal, so a surface the client must not reach cannot be reached by sending a different argument, because there is no argument to send
• What a client can never see is enforced by there being no endpoint rather than by hiding a control. Nine surfaces are absent from the portal entirely: the acceptance file and its screening checks, the commercials, the stakeholder map, the RAID register, the working papers, the hypothesis tree and interview programme, the lessons learned, the workspace directory, and meeting transcripts. Each one carries the reason it is absent, written where the next person tempted to add a convenient route will read it. A filter can be forgotten. A route nobody wrote cannot be called
• The commercial summary is the one narrow exception to that list, and it is a different thing from the commercials the portal denies. What a client can see there is what they agreed to pay, what they agreed to pay on top of it through approved changes, and what has been invoiced to them: three figures already on documents they hold. The firm own position stays on the firm side, so cost rates, bill rates, margin, utilisation, internal effort, the budget the firm set itself and its estimate at completion appear nowhere. The whole surface is off unless the firm turns on sharing the budget with the client in Client Delivery settings, and while it is off the tab is not offered and the address answers exactly as an engagement the reader has no access to, so a refusal never confirms there is a figure being withheld
• The reads that do exist are filtered in the query rather than after it, because a read that pulls internal rows and drops them afterwards has already put them in memory beside a client session. A deliverable, a thread or a status report reaches the portal only when it is marked for the client audience; a thread has to be non-confidential as well, since those are two independent flags and checking one of them is the mistake; a status report has to have been issued rather than merely approved; and minutes have to have been circulated to the client or already approved by them, so the set a client sees is the minutes they still owe a decision on together with the record of the ones they have signed
• A thread is a conversation rather than a title. Opening one shows the posts on it, oldest first, each marked as coming from the client side or from the engagement team, and a reply is stored and read back rather than acknowledged and forgotten. The list says how many posts each thread carries so a client can see where the conversation is without opening every one of them. A thread reaches the portal only where it is marked for the client audience and is not confidential, and a post carries the marking that was true when it was written, so reclassifying a thread later never publishes a post nobody expected a client to read and never hides a client post from the person who wrote it
• Every portal register is served a page at a time rather than in full, with a control that fetches the next page where there is one. On a long-running engagement the alternative is the whole history of the work arriving on every page load, which is slow to the point of unusable. The count on the overview reads as a figure followed by a plus sign where the register holds more than the page it counted, rather than reporting a page as a total
• The engagement summary is a small projection rather than the record, so a column added later is withheld by default instead of exposed by default. The client is given the name, the code, the status, the dates and the single overall traffic light, never the seven-dimension breakdown that carries what the firm privately thinks of its own budget and resourcing. Budget appears at all only where the firm turned that on, and never as a value, a rate or a margin. A team member appears only where somebody marked them visible to the client, and without an email address, because a directory of everybody who works on the engagement is a phishing target and handing one over is the decision of the firm rather than of the client
• Where the portal exposes the plan at all it exposes milestones rather than the plan itself, because a full plan handed over invites line-by-line management of work that was sold as an outcome and discloses internal task structure nobody agreed to show. The milestones screen is the client answer to where the work has got to: each milestone carries its title, the date it is planned for or the date it landed on, and how far it has progressed. What is withheld is everything else on the same plan row, including the internal task it was adopted from, the owner inside the firm, the effort estimated against it, its float and its position on the critical path
• The information request list is the reason the portal exists, because the question a client signs in to ask is what the firm needs from them. Each request carries its own items, so a file is uploaded against the specific thing it answers rather than into a general drop box, and marking a request not applicable requires a written reason: a silent not-applicable is indistinguishable from a request nobody answered
• Documents the firm has shared appear on the request they belong to and on the deliverable they belong to, each with a control that saves the file. A template, a worked example or the schedule being asked about sits beside the request that asks for it, and the document behind a deliverable sits beside the control that signs it off, because asking somebody to accept a deliverable they cannot open is asking them to accept a title. A document reaches a client only where somebody at the firm marked it for the client audience and the upload finished, so a half-finished upload is never offered
• The document library is the same set on one screen, in both directions. It carries everything the firm has shared on the engagement, including the documents that hang from nothing in particular, which is where a contract, an engagement letter or a firm template goes, and everything the client has sent. Each row says which side it came from. Sharing a document with the client is a decision somebody takes on the file itself rather than a property of where it was uploaded: files default to internal, the control beside each one shares it or withdraws it again, and both directions are recorded on the audit log with who decided. Withdrawing does not delete anything, and does not claim to: a client who has already saved a document still holds it
• A client can send a document nobody asked for. Until now the only way to send anything was against a specific line of a specific information request, so somebody holding a board pack, a signed contract or a schedule the firm had not thought to ask for emailed it instead. The send control sits on the document library, the file goes through the same extension, type and size checks as every other upload, and it appears in the library marked as sent by the client organisation once its bytes have been verified against storage
• Who is on the engagement is its own screen, and it answers from both sides. The engagement team lists the people the firm marked visible to the client, with an address only for those the firm chose to share one for, which is a decision taken per person rather than for the whole team. Your own organisation lists the people who can open this portal: their name, the authority their seat carries, whether they have accepted their invitation, and when they last opened it. No identifier of any kind appears, and a seat whose access has been revoked is absent rather than shown as inactive
• Portal uploads attach evidence to any open information-request item through a three-step client flow: request a presigned upload ticket, PUT the bytes to storage, then finalize; the finalize step HEADs the object so the storage-declared size is authoritative over the caller-reported number and a hostile caller cannot bypass the configured cap
• Signing off is a decision with three answers rather than a single accept: approve, approve with comments, or request changes. The last two require a comment, because work sent back with no reason gives the team nothing to act on, and all three require the person to type their name before the server accepts the sign-off. Approving moves the deliverable to accepted and stamps the moment it happened. Requesting changes sends it to revision instead
• An invitation is issued for one person against one engagement, and the token it carries lasts fourteen days and can be used once. Every refusal reads the same, whether the token was never valid, has expired, has already been used, or has been revoked, because a message that tells the four apart tells somebody working through guesses which tokens exist. Acceptance is rate limited for the same reason
• What opens the portal is the access grant on the engagement rather than the invitation. A grant names the person, records the reason it was given, and can carry an expiry, and that reason is the only thing that makes an access review possible six months later, when the question is not who has access but why anybody gave it to them. Every portal read and every portal write starts from the grant rather than from the engagement, so a request from somebody who holds none is refused before an engagement row is read at all
• A missing grant, a revoked grant, an expired grant and an engagement belonging to another workspace all produce the same not-found answer. Telling somebody that their access has expired confirms the engagement exists, which is a disclosure to anybody trying identifiers, so the portal answers all four the same way and records the real reason where an operator can read it
• Revoking access lands on the next request rather than at the next sign-in, because nothing in the portal caches the decision: every read, every write and every download asks again. A download link already in the client's hands stops working at the moment it is used, since the signature is checked and then the grant is checked again before the file is handed over. The live update stream is dropped from any browser tab still open rather than continuing until it reconnects, and the session is ended so the token already issued stops working immediately, which matters because a guest account reaches tasks and comments that never consult an engagement grant at all
• A portal download is a short-lived signed link rather than a durable address. It is signed with a server-side secret over the file, the expiry and the workspace, lasts five minutes, and is verified again at the moment of use against five independent things: the signature, the expiry, the file still being marked for the client, the object still sitting under that workspace prefix in storage, and the grant still being live. A link signed for one workspace cannot open a file in another, and every failed check returns the same answer so the response distinguishes nothing about which one failed. Using the link hands over the file itself, served through Atlas rather than by redirecting the reader to the storage layer, and it is always saved rather than opened in the tab
• Every write a client makes is rate limited: twenty actions a minute for one person on one engagement, refused with its own distinct response so an operator log can tell a throttle from an ordinary refusal. Every write that changes something is also recorded, so submitting a request, marking one not applicable, completing an action, signing off, approving minutes, replying to a thread and acknowledging a change each leave an audit row behind them
• Change requests are a list the client can read, and a decision they take on a change they have been shown. The list carries every change the firm has shared: what it is called, the firm reference, where it has got to, how many days it moves the schedule and what it costs, in the currency of the engagement. A draft is never on it, because a draft is the firm working out what to propose. Every decided state is, including deferred and withdrawn, so a client asked about a change last month can find out what happened to it rather than watching it disappear. Each row says whether that reader still owes an answer or when they gave one, and an amount the firm has not costed yet reads as not yet priced rather than as nothing, since a client who reads a blank for an unpriced change approves it believing it is free
• Opening a change shows what is being decided before it offers any way to decide it. The title, the reference, the state, the schedule effect and the cost sit above the three answers, and no control appears at all until the change has been read: approving a schedule impact and a cost impact that were never on the screen is not a decision anybody can be held to. The client records approve, reject, or ask for more information, a comment is required on the last two, and every answer is signed by typing a name, exactly as a deliverable sign-off is. The answer is kept as an approval record on the engagement, so it reaches the firm and the screen reads back the date it was given rather than continuing to ask. It does not itself move the change request, because approval runs through the internal change board. What a client sees of a change is deliberately narrower than what the firm holds: the internal assessment written for the change board, the effect on the margin the firm makes, and who inside the firm has signed it off so far are all absent, and they are absent from the query rather than removed from the answer
• The four notification switches a client controls, covering status reports, approvals waiting on that person, replies to them and their own reminders, have a screen of their own on the portal. The choice is stored against that person on that engagement and the screen opens on what was saved, so a client who turns three of them off sees three of them off the next time they sign in. A seat that has never touched the screen has every switch on, which is the answer the server gives rather than a guess the screen makes. Four and only four is deliberate: a general settings write on a portal surface is how a field nobody meant to expose becomes writable by a guest
• The portal carries your brand rather than the Atlas one. The display name and accent colour set in Settings, Branding appear in the portal header, and for a client who has already opened the portal in that browser tab the accent colour is applied before the page paints rather than changing after it has loaded. The firm name itself appears once the page has confirmed who is reading
• Six widgets for the Home board, so the portfolio can be read without opening the module: engagement portfolio health, the engagements rated red or amber by name, open RAID counted by heat band, information requests past their due date, actions owed in the next seven days, and change requests still waiting for a decision. Each reads the same firm-wide register its own screen reads, so a widget and the register it summarises cannot disagree. Every band, rating and status is written out in words as well as coloured, and each widget states its own limits: the at-risk list gives the firm-wide count underneath when it is showing fewer, and the RAID counts say so when they came from a full page of the register
• Every screen of one engagement now sits inside one workspace. The engagement name, its reference, the health lights, the dates, the phase it is standing in and the week it has reached are read once and stay on screen while you move between the twenty-seven tabs, rather than being drawn again by each of them. The tabs are grouped into the three things a consultant actually does, running the work, governing it, and delivering it, and a left rail carries the phases and the workstreams with their own health. A pane on the right shows what the tab you are on needs beside it, and falls back to the engagement pulse everywhere else rather than sitting empty. A tab that fails now fails inside the workspace, so the header and the way out of it stay where they were
• An engagement timeline: what happened, and when, newest first. A short list of things reach it and nothing else. A risk, issue, assumption, dependency or decision raised, closed out, shared with the client or withdrawn from them; a change request approved or refused; a status report issued to the client; a deliverable signed off; minutes approved; and the acceptance gate decided. Everything else an engagement records, every field edit and every draft save, stays off it deliberately, because a record of everything is a record nobody reads. Each entry is written in the same transaction as the thing it describes, so the timeline cannot claim a decision the register never took. The sign-off entry is the one kind marked for the client, since a sign-off is a joint act and both sides see it; withdrawing a risk from a client is recorded internally only, because the reason for taking something back is a deliberation that stays inside the firm
• The engagement register carries an open work column: how many register items are open on each engagement, how many questions are still waiting on somebody, and how many actions are past the date they were promised. The three figures are kept on the engagement itself and moved in the same transaction as the thing they count, so a list of four hundred engagements is one read rather than four hundred, and closing a risk moves the number the moment you close it rather than the next time something is recalculated
• The engagement chooses the decision model its matrix runs under, and it can be changed after the engagement starts. RACI, RASCI, DACI and RAPID each use a different set of letters, so changing the model re-labels every seat that already exists rather than only the ones written afterwards. A seat holding a role the new model does not have, an Informed party moving to RAPID or an Agree moving back to RACI, refuses the change and names how many stand in the way, because a matrix that quietly lost its Informed parties is worse than one that would not move.
• A matrix can be published, which is what makes agreement mean anything. Publishing is refused while a blocking finding stands, and it stamps only the seats that were still drafts, so a settled matrix gaining one area does not ask everybody to agree again. Once a seat is published the person named on it can confirm it is theirs, and nobody can confirm on anybody else behalf. Editing a seat afterwards clears both the publication and the agreement, because what stands is no longer what was agreed.
• The matrix covers more than areas of responsibility. A deliverable, a workstream and a phase can each carry a row, and the parts of the engagement nobody holds anything against are listed with the control that assigns a letter against all of them at once. Somebody rolling off the engagement can be taken off the whole matrix in one action, which reports what that broke rather than leaving it to be discovered.
• The matrix downloads as a spreadsheet, a document or a PDF, laid out with subjects down and people across, with the findings underneath so a circulated copy does not hide them. Letters are named in the vocabulary of the model the engagement runs, so a RAPID matrix is exported in RAPID letters.
• The engagement register is read a page at a time and can be read to the end. Show more engagements continues from where the last page stopped rather than from a position counted down from the top, so an engagement created while you are reading does not push another one off the end unseen. A firm with four hundred live engagements reaches all four hundred: before this, the list answered at most two hundred and said nothing about the rest. The list can also be ordered by when it was last worked on, by when it was opened, by name, or by which engagement finishes soonest, and narrowed by health band and by start and end date. One limit is worth knowing before you rely on it: the default order is by when an engagement was last worked on, and that moves whenever anybody touches the engagement, so on a busy portfolio an engagement edited while you are part way through can move above where you have already read and not appear. Order by Newest to walk the whole register exactly, because the date an engagement was opened never changes.
• Every firm-wide register names the engagement each row belongs to, by its name with its code underneath, and links to it. Six screens gather work across the whole firm, the RAID register, the meetings, the information requests, the actions, the approvals and the exports, and five of them used to print the stored record identifier in that column instead, either always or whenever the row carried no reference of its own. An engagement that cannot be named, because it has been deleted or sits behind a barrier, reads as an engagement to open rather than as a string of characters.
• The view the engagement register is showing is part of its address. Opening /delivery/engagements?view=all opens the whole register, choosing a tab puts it in the address, and returning to the default tab takes it back out, so a filtered register can be linked to, shared and reloaded. The empty state on each of the six firm-wide registers points here, and until this was wired that link landed on the Delivering tab instead, which on a firm whose engagements are all mobilising is the same empty screen a second time.
• A closed engagement can be reopened from its closure screen, which returns it to closure so a late entry, a late change request or a correction can be booked against it. Only an owner or an admin may do it, a written reason is required, and the reopening is recorded on the engagement timeline as well as on the audit trail. The reason the engagement was closed for is kept: the reopening reason is recorded beside it rather than over it. An engagement that was terminated or cancelled cannot be reopened, because a termination is a contractual position rather than a delivery state, and the closure pack already issued is not retracted.
• Five drafting capabilities on the Assistant tab of an engagement: the prose of a status report written from live register state, minutes drafted from a meeting transcript, register items proposed from minutes and threads, a quality pre-check of a deliverable against its own acceptance criteria, and an explanation of the health score read from its seven signals. Every one of them proposes and none of them writes. A proposal waits on the Assistant tab until somebody accepts named parts of it, and accepting is the only action that changes a register
• An engagement is run under one of three operating models, and the workspace reshapes to it. A strategy case (advice, research, due diligence, a retainer) is answered through a hypothesis tree, a storyline and benchmark exhibits, and is read on case margin, leverage and partner-equivalent days. An assurance engagement (an audit) is run out of a working paper file with a preparer and reviewer sign-off hierarchy and an archival deadline, and is read on realisation, work in progress, lock-up and recovery. Managed delivery (a managed service, an implementation, a transformation, staff augmentation, training, interim management) is read on service-level attainment, utilisation, days sales outstanding and velocity. The model follows the engagement type rather than being set separately, so the two can never disagree, and changing the type reshapes the workspace
• Reshaping moves a screen and never removes one. Six of the thirty tabs are promoted on some models and not on others, and the ones that are not promoted stay routable under All surfaces at the end of the tab strip. A screen the model does not ask for, on an engagement that has records on it anyway, is promoted back into the strip in a Retained records group with the number of rows behind it, so re-scoping a case as a programme cannot bury the hypothesis tree somebody already built
• The gates each model must clear are the gates that mean something on it. An independence declaration, partner rotation, the engagement quality control review and the archival of the working paper file are mandatory on an assurance engagement and absent from a training engagement, where there is nothing to be independent of. The competition-law review on a benchmark is mandatory on a strategy case only, and the service-level register is mandatory on managed delivery only. Client and engagement acceptance is mandatory on all three, because no firm skips it
• The portfolio states how the firm divides across the three operating models, including a bucket for any engagement whose type is not classified, so the parts always add up to the whole
• A status report records which of its five narrative fields still read as a model wrote them, and a field leaves that list the moment somebody edits it. The list therefore means that nobody has been over those words, which is the only reading worth putting in front of a client

• The operating model is derived from the engagement type and there is no second field for it. To change how a workspace is shaped, change the type on the engagement. An engagement whose type this release does not classify is reshaped not at all: every tab shows, which is how the workspace behaved before operating models existed
• A tab that is not promoted is still reachable. Nothing is ever hidden outright, so no record becomes unreachable because somebody changed an engagement type
• The drafting capabilities are off until your firm turns them on, and off is the default. Turning them on sends engagement content to your configured model provider: register titles, milestone and thread counts, a meeting transcript where you ask for minutes, and a deliverable text where you ask for a pre-check. A draft built for the client audience is built from a narrowed read, so a confidential register row is not summarised into a sentence that carries no confidentiality marking of its own. The firm-wide budget cap and the model fallback are the same ones the rest of Atlas uses, so drafting is refused rather than billed once the daily cap is reached.
• Nothing a model produces reaches a register on its own. Every capability produces a proposal, a person accepts named parts of it, and the acceptance is the only write. A proposal that is declined is kept with the decision, because a firm that cannot see what it turned down cannot tell whether the drafting is any good. Minutes cannot be written over once they have been circulated, and a report that has been approved or issued cannot be drafted onto at all.
• A page that fails inside the portal, and an address inside the portal that opens nothing, both stay inside the portal: the firm brand, the header and the caching rules are the same as on a screen that worked. Neither says whether the thing that was asked for exists, because a message that told a stale link from a withdrawn one would confirm an engagement to whoever is holding the link. A failure carries a reference the client can quote to their engagement team, and never the internal message behind it
• A portal page is never stored by a shared cache and is never indexed by a search engine, so an engagement address cannot turn up in a search result or be handed to the next person through a company proxy. The credit line in the portal header cannot be removed today, whatever branding is set.
• The client portal shows a record only where somebody marked it for the client, and never where it is marked confidential. Audience and confidentiality are two separate switches on purpose, so a status report or a meeting written for the client audience and then flagged confidential stays inside the firm. Nothing reaches the portal by default, and a record the firm has not shared reads to a client exactly like one that does not exist. Marking a record for the client is a decision rather than a field: on the risk register, the change register and the status reports it is made through one control that shares in a click and asks for a written reason before it will withdraw, and both halves are recorded on the engagement timeline and in the audit log. The ordinary edit screens for those records refuse the field, so there is no quieter way to reach the same effect and the register can always say who decided to show a client something.
• Acceptance is not permanent. A clean decision lasts a year and a conditional one lasts six months, and an expired acceptance blocks work until the continuance is run. Screening clearances expire on their own schedule too, so a cleared check from eighteen months ago counts as outstanding.
• Readiness shows every blocker at once rather than one at a time. That is deliberate: a gate that reveals one reason per attempt turns a short conversation into several days.
• A benchmark cannot enter a client-facing deliverable without a recorded competition-law review, and the refusal blocks rather than warns. Comparing price or cost data across a client's competitors is a serious matter in most jurisdictions, so the review is a separate act by somebody with admin rights and cannot be asserted by the person who drafted the exhibit. Editing the metric definition, the peer set, the data vintage or the client value withdraws an existing review, because the reviewed exhibit and the edited one are no longer the same exhibit.
• The health history is recorded once a day per engagement by a scheduled pass, so a reading appears the day after an engagement starts being delivered rather than immediately. A pass that had nothing to measure records nothing at all: an engagement with no delivery history yet shows no readings rather than a score of zero. Milestone slip readings are taken by the same kind of pass, and the plan tab offers a control to take one now when a report is due before the next pass.
• Readiness is a gate and not only a report. Moving an engagement into Mobilising is refused outright while any blocker stands, and the refusal carries the same list the readiness panel shows, so whatever asked for the move can name each outstanding check and instrument rather than reporting only that something is missing. That move runs through the API today, because the lifecycle has no screen control yet. An engagement with no acceptance file at all is refused too: it has run no checks whatever, so it is the least ready of all rather than the most. Every other move is left alone, because a gate on the way in must not become a trap for work that is already running.
• Approving a change never edits the contract value. Approved change accumulates in its own figure so the signed number stays legible, and every report shows the sum.
• Two of the three open work figures on the engagement register are exact whenever you read them, because they only change when somebody writes. The count of overdue actions is different: an action becomes late because a date passed rather than because anybody touched it, so that figure is proved against the register four times an hour and can be up to a quarter of an hour behind. The portfolio reports how many engagements were proved recently and how many were not, so a stopped check shows on the surface rather than appearing as a portfolio where nothing runs late.
• The engagement health score is recomputed hourly rather than at the moment you read it, so it describes the engagement as it stood at the time shown beside it. The portfolio rating stops using a score once it is more than a day old and reports how many it treated that way, because a score nobody has refreshed says more about the recompute having stopped than about the engagement. An engagement in the pipeline or already closed is not scored at all.
• The economics summary and the workpaper index have no client edition in any format. Asking for one is refused rather than quietly handed back as the internal document.
• Interviews are not attributable by default. An interviewee who did not agree to be named appears everywhere as an anonymised label, including in every export, and consent to be interviewed is recorded separately from consent to be named.
• A working paper file cannot be unlocked once it is locked, and a paper cannot be removed from a locked file. Papers can still be added, and every addition after the lock records who added it, why, and who approved it.
• Nobody can approve their own expense claim, and nobody can review their own working paper.
• Three closure items are derived from live data rather than ticked by hand, and asking to complete one is refused. If access is still open, the way to close that item is to de-provision the access, not to tick the box. A derived item that has been explicitly waived stays waived even if the underlying signal goes back the wrong way, because a waiver is a decision somebody took and a signal does not get to overrule it. The closure screen offers no complete control at all on a derived item, and says what to close instead, because an action that is always refused is worse than no action.
• An asset is not reusable because somebody says so. It becomes reusable when it has been sanitised and, where the engagement required it, client consent has been recorded. Asking to reuse an asset that is missing either half is refused, and the refusal names which half.
• An information barrier is not a label. An excluded party is denied even when their grant is live, unexpired and correctly scoped, because a barrier that only filtered the interface would be walked around by anybody with an API client. Being on the permitted-crosser list is not itself access either: the crossing has to be approved and recorded, and it lifts only the barrier it was approved against.
• A barrier names the points it is enforced at, and three of the seven are live: the portal grant check, the engagement register and signed downloads. The engagement register means the whole engagement, not its front page: every surface that hangs off it asks the same question before reading it and before writing to it, so there is no second door. The question covers both reasons an engagement can be out of reach, the barrier and restricted access, because a check that knows one of them publishes the other. A barrier that names only chat channels will not hide engagement records, which is deliberate so a narrow wall does not become a blackout. The other four name a surface that cannot leak an engagement today. Chat channels carry no engagement link, engagements are not in the search index, and meeting attendance lives inside the engagement and is already covered by the register. Time entries do carry the engagement, but no screen or export discloses it: every reading of time is either your own or a total of hours, so the only engagement a timesheet can reveal to you is one you booked to yourself. Naming one of those four on a barrier records an intention rather than raising a wall, so do not rely on one alone.
• Marking a follow-up as seen is not the same as completing it. Seeing it records that somebody read it and nothing more: the chase keeps running until it is completed or cancelled. That is deliberate, because the alternative is a button that quietly stops a chase and leaves everybody believing it was handled.
• A follow-up can be snoozed, but not into the past. Snoozing to a time that has already gone would fire again on the next sweep and read as the snooze having been ignored, so it is refused. Pausing is the way to stop one indefinitely, and a paused follow-up keeps its due date so resuming puts it back where it was.
• A chase a rule raised reads in your own language. The rule runs on a server, which has no reader and therefore no language, so it records what happened and the values involved rather than a finished sentence, and the wording is assembled when somebody opens it. Two people working in two languages see the same record correctly, and a title somebody typed themselves is left exactly as they wrote it.
• The rules create a chase, they do not resolve one. A follow-up raised because a deliverable is due stays until somebody completes or cancels it, even if the deliverable ships in the meantime, because Atlas knows the date passed and not whether the work happened.
• A follow-up is chased in the application only. Email is recorded as a channel and is not yet delivered, and the delivery record says so on each attempt rather than leaving somebody to assume a message went out. A recipient who has turned off that kind of notification is recorded as skipped rather than as sent, for the same reason.
• A cancelled follow-up is kept, not deleted. That a chase existed and was called off is the thing somebody asks about later, and a sweep rule that fires again afterwards raises a new chase rather than reviving the one that was dismissed.
• The list of nationalities on an export controlled engagement is the list of nationalities **permitted** on the team, and an empty list means unrestricted. The plan names the field a restriction and does not say which way it reads, so it is settled as an allowlist: under a denylist an unrecorded nationality would pass, and for this control the unknown case has to be refused.
• US person status is recorded on the employee record in People, as a choice between established as a US person, established as not one, and not established. It is a closed choice rather than free text because the export control filter refuses any value it does not recognise, so a typed variant would quietly make somebody unstaffable with no error anywhere.
• Export control needs a nationality and a US person status on the employee record to work at all. US person is held separately from nationality on purpose, because a US person is a citizen, a lawful permanent resident or a protected individual, and inferring that from a nationality would be wrong in both directions. Where neither is recorded, staffing on an export controlled engagement is refused rather than waved through.
• Do not tell anybody that a suspicious activity report has been filed. Saying so is a criminal offence in most of the jurisdictions this product is sold into, and the person most likely to do it by accident is the partner asking their client why acceptance is taking so long. That is why the lock conceals rather than merely restricts, and why there is no notification, no automation event anybody should subscribe to, and no export that carries it.
• With nobody appointed as reporting officer, nobody can see or file a report at all. That is deliberate: a misconfigured firm discloses nothing rather than everything. The appointment is made in Client Delivery settings, and changing it is audited, because appointing yourself is the way past the lock and the record of who did it is the compensating control.
• Filing is one way. There is no route that clears the flag, because a report being withdrawn is something that happens to it at the financial intelligence unit, not something that happens to the fact that the firm filed one.
• Screening does not happen in Atlas. Atlas records that it happened, against which lists and with what conclusion: it does not call a sanctions provider, and it does not decide whether a hit is your client. A register with no runs in it means nobody has recorded a screen, not that the client is clear.
• Nobody can approve their own screening disposition. Calling a hit a true match and approving that call are two acts by two people, and asking to approve your own is refused rather than warned about, because a single person closing a sanctions hit is the finding a regulator opens with.
• The fifty percent test is arithmetic over the owners somebody has recorded, so it is only as complete as the register behind it. Nought percent blocked because nobody was screened is not nought percent clear, and the assessment says which of the two it is looking at rather than reporting a reassuring number.
• Permission to quote a client and permission to use them as a reference are recorded separately, and neither is assumed. A response with no words cannot be marked quotable at all, and where somebody answered anonymously the quotable list returns their words without their name, so a quote cannot be attributed to a person who did not agree to be named.
• A complaint cannot be closed without both a root cause and a preventive action. Either on its own is half an answer: a cause with no action is a diagnosis nobody acted on, and an action with no cause is a change nobody can justify. This is the rule the record exists for, because a complaint tracked in email is a complaint that becomes a claim.
• The obligation register only knows the clauses somebody has extracted into it. Atlas does not read the contract: an empty register means nothing has been entered, not that the contract asks for nothing, so the due panel showing nothing outstanding is only as trustworthy as the extraction behind it.
• Marking a clause met is refused where the clause records the evidence it demands and no attachment has been recorded, and waiving a clause is refused without a stated reason. Both are refusals rather than warnings, because an obligation marked satisfied on nothing more than an assurance is the same evidential position as one nobody tracked at all.
• A RACI cell or a thread that points at part of the engagement, a deliverable, a phase, a RAID item or the engagement itself, is checked against that engagement before it is stored. A pointer naming something in another engagement, something already deleted, or nothing at all is refused rather than saved, so a matrix cannot show an assignment against a subject nobody can open. A thread may point at nothing, which is the common case, but it cannot carry half a pointer.
• The engagement partner cannot appoint their own quality reviewer, and cannot be the reviewer. A former engagement partner must be off the engagement for two years before reviewing it. These are refusals, not warnings, because a reviewer checking their own prior judgments is not a review.
• A quality review cannot be completed while any matter is unresolved, and cannot be completed on or after the report date. Both are hard constraints. A review that finishes after the report has not reviewed the report, and an unresolved matter signed off is the finding an inspection opens with.
• A difference of opinion blocks report dating from the moment it is raised, and keeps blocking until somebody records how it was resolved. The safe default for that gate is to hold. A resolved difference stays on the register showing how it was settled rather than disappearing, because that a disagreement happened is exactly what an inspection asks for.
• A non-audit service is recorded even when the audit-committee pre-approval reference is missing, and the gap is returned as a warning. Refusing the record would push a delivered service out of the register, which is the worse outcome; the fee-cap position must reflect what actually happened. The gap is recomputed every time the register is read rather than stored, so a rule change applies to everything already recorded.
• The three-year audit fee is typed in rather than read from the record. It is a client-relationship figure spanning engagements Atlas may never have seen, and the cap is a ratio, so Atlas declines to state a position until the number is given rather than defaulting it to zero and reporting a ratio of nothing.
• The rotation register is kept per client rather than per engagement, because a rotation limit runs against the client relationship and not against any one piece of work. An engagement with no client on record shows the register as unavailable rather than as empty, since an empty list would read as nobody being near a limit when the truth is that nothing was checked.
• Naming a different person in a key-personnel role is usually a contractual event, not an internal one. Where the contract requires the client to approve that appointment, Atlas will not let the staffing request be confirmed until the approval is recorded, so the step cannot be skipped by whoever is in a hurry to staff the job.
• A handover can complete with defects still open, because real ones do. What Atlas will not allow is for that to be silent: completing knowledge transfer records the open-defect count on the audit event, and the transition plan warns anybody reading it that the receiving team is inheriting them.
• Editing the handover plan replaces it rather than merging, so the form arrives filled in from the current plan. A blank form against a replacing endpoint would quietly drop every field the editor did not happen to retype, and nobody would notice until the receiving team asked where the hypercare dates went.
• A person is chosen by name, never typed. The identifiers these records store are internal, and a field that asked somebody to type one guaranteed two failures: records naming people who were never in the workspace, and a screen that reports a decision as having been taken by a string of characters. Where a stored identifier no longer resolves to a member, a form says the person is not in this workspace, and a register shows the identifier itself rather than blanking, because an external adviser or a partner who has left the firm has to stay identifiable on a record that names them. On the insider list the account key is hidden when it resolves to the same person as the recorded full name, since a line repeating the name above it is not a second fact.
• Every category, trigger reason and declaration type on these screens is a translated label rather than the stored value. A heading reading COMMERCIAL is a database identifier on screen, and title-casing it to Commercial only makes it English in every language. Where a value is newer than the translations, the label falls back to readable words rather than showing the untranslated key.
• Changing a follow-up rule is an administrative action, separate from being able to edit an engagement. Turning off the rule that chases access still live on a closed engagement is a security decision, so it sits with whoever administers the module rather than with everybody who works on one.
• A client reaches the engagements they hold a seat on, and nothing else. The address /portal lists them, and a client who holds exactly one seat is taken straight to it rather than shown a list of one. The list is built from the seats that person holds and is never wider than what the engagement screens themselves allow, so a seat that has been revoked, has expired, sits behind an information barrier or belongs to another workspace is absent from it. A request for any other engagement is refused as not found, whether or not it exists.
• An empty portal says which kind of empty it is. Nobody has invited you yet, your access has been removed, or you hold an invitation you have not opened. Those are three different situations and only one of them is a reason to contact the firm, so the screen says which one rather than reporting that there is nothing here.
• Accepting an invitation provisions the access it promises. Acceptance creates the guest membership and the access grant on the engagement in one transaction, and reports back whether the seat exists rather than assuming it. A person who has never accepted holds no seat, and is refused as not found, which is the same answer given to somebody who was never invited at all.
• Accepting also moves your session onto the workspace that holds the seat. The membership and the grant are written in the firm workspace while a client is signed in to their own, and every portal read resolves grants inside the workspace the session names, so acceptance used to succeed and then leave the client on a portal that answered "This engagement is not available" on every screen. The acceptance now names that workspace and the screen switches to it before opening the engagement. A client who advises several firms is moved to the one that sent the invitation, and a client already reading that firm is left where they are. Where the switch itself fails, the screen says so and offers to try again rather than sending them onward: the seat is real, and the invitation has already been spent, so re-accepting would tell them their invitation is invalid.
• Issuing an invitation, revoking one, and granting or revoking access all run through the API today. None of the four has a screen, and none has a method in the Atlas client library either, so a firm running the portal is calling those endpoints directly.
• Sharing a document with the client has a screen only where the document sits on an information request. That is where the control lives, on the file list of the request itself, and it covers every file the firm attaches while answering or asking. A document attached to the engagement rather than to a request, which is where a contract or an engagement letter goes, can be shared through the API and has no screen yet, because the module has no engagement-wide file list to put the control on. Until it does, the library shows such a document to the client only once somebody has called that endpoint.
• Revoking access ends it everywhere at once. The next request is refused, the engagement leaves the list they see at /portal, a download link already issued stops resolving, the live update stream is dropped from any browser tab still open, and the session itself is ended so the access token they are already holding stops working rather than lasting out its hour. Where that was the last seat they held, their guest membership is disabled as well, which both closes the workspace to them and frees the seat against your plan. What none of it can do is retract a file already downloaded. The audit record says which file left and when, which is the only honest answer to the question of what they still have.
• Every client seat counts against the guest limit on your plan, and it is counted twice over: once when the invitation is issued, because a batch of invitations sent before anybody accepts would otherwise all be free, and again when it is accepted. Re-sending an invitation to somebody who already holds a seat costs nothing, since a seat is held per workspace rather than per engagement, and inviting the same person to a second engagement therefore adds nothing to the bill. A seat freed by a revocation is genuinely free, and using it again is charged again.
• Approving minutes is refused once minutes are approved. The portal meetings list carries minutes that have been circulated to the client as well as ones already approved, so the approve control appears on exactly the minutes still waiting on a decision and the record of the ones already signed stays visible beside them.
• A sign-off moves the deliverable: approving marks it accepted and stamps the moment, and requesting changes sends it to revision. What survives beyond that movement is thin today. The audit record names the engagement, the deliverable and the account the decision came from, and the typed name and the comment are required by the server without being kept, so approving and approving with comments cannot be told apart afterwards, and the evidence of who signed is the account and the timestamp rather than a signature.
• None of the client actions is a general write, and each refuses a second answer over a settled record. An action that is already closed or resolved cannot be completed again. A closed or resolved thread cannot be replied to, and says so rather than swallowing the message. An information request that has been accepted or withdrawn cannot be resubmitted, because that is a rewrite of history rather than a new answer.
• The portal is not callable with a personal access token and not through OAuth. Every portal route is scoped to the access the caller was given and can reach nothing beyond it, and the other ways into the API are closed to a client deliberately: every additional way in is another thing to get right, and a client scripting against the firm API is not a flow anybody asked for.
• A signed download link is checked against the information barriers in force at the moment it is minted, on top of the grant check every portal request already makes. A link outlives the request that produced it, so the wall has to be consulted before a durable credential is handed out rather than only when somebody asks for a page.
• Sharing a risk with a client does not unshare what they have already read. Withdrawing takes the item out of the next client edition of the register and out of any client-facing read built from it, and the withdrawal is recorded; it cannot recall a document already sent.
• The heat map plots only what has both axes. An assumption and a decision are never scored, so they are counted beside the grid rather than placed on it: putting them at the safest corner would report an engagement in better shape than it is.
• Reopening a closed engagement returns it to closure rather than to delivery. That is deliberate: reopening corrects the record, and moving an engagement back to being delivered would restart burn, utilisation and the health score as though the work had resumed. Work that genuinely resumes is a change request or a new engagement. An engagement that was terminated for cause, terminated for convenience or cancelled is refused outright, and the refusal names the status so the reader can see why.
• Client Delivery is a paid module.

1. 1Open Client Delivery from the sidebar, or press the command key and K and search for Engagements.
2. 2If your firm already runs this work somewhere else, import it rather than retyping it. Import, in the sidebar under Client Delivery, takes a comma-separated file or a spreadsheet workbook of up to 2000 rows and creates engagements and client contacts from it. The three registers that belong to one engagement, the RAID register, the plan and the stakeholder list, are imported from the Import tab on the engagement itself.
3. 3Every import runs in the same three steps. Choose what you are importing, choose the file, and check the columns Atlas matched to each field by its heading, correcting anything it got wrong. Then read the preview: it lists every row of your file with what will happen to it and why, before anything is written. A row that breaks a rule says which field and which rule, by row number, and the rest of the file still imports.
4. 4Importing the same file twice creates nothing the second time. Each thing you can import says on the screen what identifies a row: an engagement is its code, a RAID item is its kind and title, a plan item is its title and its parent, a stakeholder is their email address, and a client contact is their email address within the client account. Run it without writing anything first if you want to see the result before committing to it.
5. 5Start an engagement with New engagement, which sits in the sidebar under Client Delivery, on the header of the module home and of the engagement register, and on every empty state that has nothing to show you yet.
6. 6The create flow asks five questions in order. First the things the record cannot exist without: which client the engagement is for, what it is called, the code it is known by, what kind of work it is, and how it is paid for. You cannot move past that step until all five are answered, so the create can no longer be refused for a field nobody asked you about. If your workspace has no clients yet, record one from that step without leaving the flow.
7. 7The remaining steps are optional. Choose a playbook to seed the phases, workstreams, deliverables, meeting cadence and opening risks, set the dates and the commercial figures, name the engagement partner and manager, then read the review step and create. Nothing is written until you create, and a playbook can only be applied at this moment.
8. 8Open an engagement and use the section tabs across the top to move between the overview, closure, information barriers, contract obligations, follow-ups, client voice, reusable assets, benefits, and people and handover.
9. 9Open the acceptance file and set the risk tier. Atlas creates the checks that tier requires, and adds more if the work involves personal data, subcontractors or a second jurisdiction.
10. 10Work through the checks and the legal instruments. Check readiness at any point to see everything still outstanding.
11. 11Once acceptance is granted, build the plan and capture the original baseline.
12. 12Run the work. Every register on the engagement can be added to from the register itself: the plan, the deliverables, the workstreams, the threads, the stakeholder map, the change requests and the hypothesis tree each carry an add control above the list, and the same control is offered from the empty state so a register with nothing in it is never a dead end.
13. 13Log risks and issues on the register, raise change requests when the scope moves, and record deliverables as they are submitted and accepted.
14. 14A long register is read a page at a time. Show more of the register fetches the next page from where the last one stopped rather than from a position counted from the top, so an item raised while you are reading does not push another off the end unseen. The counts beside the facets are always over the whole register and never over the page in front of you.
15. 15Give the client access to the portal when there is something for them to do. Issue an invitation for one person on this engagement, and grant that same person access to the engagement, which is what actually opens the portal for them. Both steps run through the API today, because neither has a screen yet.
16. 16Write the weekly status report from Status, then Compose a report. Atlas proposes the period that has not been reported yet, on the cycle and the reporting day your firm has configured, builds the draft from live data, and carries the lights forward from last week, so most weeks are a review rather than a rewrite. Pick the key risks from the register, write the five narrative fields, and check the preview of what the client receives before you send it anywhere. If the figures have gone stale while you were writing, refresh them: it re-reads every number and leaves every word you wrote alone.
17. 17Send the report for approval, have it approved, and then issue it. Those are three separate steps on purpose. The draft saves itself as you type, and once a report is issued it cannot be edited: correcting one means issuing a replacement that says what changed.
18. 18At the end, assemble the working paper file, confirm the review notes are cleared, and lock it. This step runs through the API today: the file, its readiness check and its lock have no screen yet, so it is the one part of the sequence you cannot do from Atlas itself.
19. 19Open Closure on the engagement. Report dating sits at the top: if the report cannot be signed yet, every reason is listed there, with the quality review and any difference of opinion directly beneath so each can be settled without leaving the screen.
20. 20Below that, create the closure checklist if it does not exist yet, then work the twenty items: complete the ones that are done, waive the ones that do not apply with a reason, and close the underlying work for the three that are derived from live data. The readiness banner turns green when every blocking item is resolved.
21. 21Revoke every client access grant once the engagement is closed. Nothing revokes one for you and nothing chases it: the daily follow-up on access still live after closure watches provisioned system access, and so does the closure item derived from it, so a portal grant left open stays open and stays quiet.
22. 22To have Atlas draft for you, open the Assistant tab on the engagement. Choose the report, the meeting or the deliverable the draft is about, then ask for the draft you want. What comes back is a proposal: select the parts you want and accept those, or decline the whole thing. Accepting is the only action that writes anything, and it writes only what you selected.
23. 23Export whatever the client or the reviewer needs from the Exports control on the engagement.
24. 24To watch the portfolio between visits, open the Dashboard, choose Add widget, and add the Client Delivery widgets you want. The board keeps its layout against your account, so it follows you to another device.

Half the tabs I expected are missing from this engagement. Where have they gone?

Nowhere. The workspace is shaped by the engagement operating model, which follows the engagement type, and the tabs that model does not promote are gathered under All surfaces at the end of the tab strip. Open it and every screen is there. If a screen the model does not promote is holding records, it is put back in the strip in a Retained records group with the number of rows on it, so nothing you have written can be out of sight.

How do I change which operating model an engagement runs under?

Change the engagement type. Advice, research, due diligence and a retainer run as a strategy case; an audit runs as an assurance engagement; a managed service, an implementation, a transformation, staff augmentation, training and interim management run as managed delivery. There is deliberately no separate operating model field, because a type and a model that could disagree would eventually disagree, and an audit whose workspace claims it is a programme is worse than no reshaping at all.

What does Atlas need before it will create an engagement?

Five things, and the create flow will not let you past its first step without them: the client the engagement is for, the engagement name, the code it is known by, the kind of work it is, and the fee model it is paid under. The code has to be unique across live engagements, so a code another engagement already uses is refused and the flow says so against that field. The client comes from the same client register the rest of Atlas uses, and if your workspace has none yet you can record one from inside the create flow rather than going somewhere else first. Everything after that step is optional and can be filled in later: the playbook, the dates, the contract value and currency, and the partner and manager.

A value was refused. Where does it say which field and why?

Under the field itself. A refusal names the field and the rule it broke, the create flow shows that rule beneath the input that carries it, and it returns you to the step that field lives on so the message sits beside the control rather than beside a summary of it. The contract value is the one people meet most often: it takes at most sixteen digits before the decimal point and two after it, so a longer figure is refused against that field. A refusal that names no field at all shows the single sentence Atlas was given, because that is the only thing there is to act on.

We have four hundred engagements in a spreadsheet. Do we have to retype them?

No. Import, under Client Delivery in the sidebar, reads a comma-separated file or a spreadsheet workbook and creates engagements and client contacts from it. The registers that belong to one engagement, the RAID register, the plan and the stakeholder list, are imported from the Import tab on that engagement. Atlas matches each column of your file to a field by its heading and shows you the match so you can correct it, then previews every row with what will happen to it and why before writing anything. A file of four hundred rows with three bad ones imports three hundred and ninety seven and tells you the row number and the rule for each of the three. Importing the same file again creates nothing, so a run you had to stop half way is safe to repeat. The limits are 2000 rows and 5 MB a file; split a bigger one and import the parts one after another. One further limit is worth knowing before you meet it: to decide whether a row of your file is already here, Atlas reads what is already there, and it reads at most 20000 rows of it. A workspace holding more engagements, client contacts, or register entries than that is told so and the import is refused rather than run, because past that point Atlas cannot tell a repeat from a new row and would create a second copy of it.

We already run this work as an Atlas project. Can the engagement pick it up?

Yes, in three places, one for each kind of thing. The project risk log moves into the RAID register from the register itself. The task list becomes plan items from the plan tab. The people on the project become the stakeholder register and the engagement team from the Import tab, and that step will not create somebody who is already on either. Each of the three refuses to run twice over the same rows, so you can carry one across, look at it, and come back for the next.

How do I put the first row into a register?

From the register itself. The plan, the deliverable register, the workstreams, the threads, the stakeholder map, the change register and the hypothesis tree each carry an add control above the list, and the empty state offers the same control, so a register with nothing in it is somewhere you can start rather than somewhere you are stuck. Two registers are filled in from elsewhere by design and say so: the acceptance file is opened by the acceptance process rather than by a button here, and the commercial picture is computed from the contract value and the commercial terms, so its empty state takes you to where those are recorded.

Who can I put on the stakeholder map?

Anybody you can identify. An entry is held against the person rather than against a row on the map, so each one needs the identifier its kind of party is known by: a colleague is chosen from your workspace, and anybody outside it is recorded with an email address. Sending the same person again corrects the entry that is already there rather than adding a second one, which is what makes the map safe to keep up to date. Somebody who exists in the client contact register is recorded here as an external party with their email address.

We closed an engagement too early. Can it be reopened?

Yes, if it is closed rather than terminated or cancelled. Open the engagement, go to Closure, and use Reopen at the foot of the screen. You need the owner or admin role and you have to write down why. The engagement returns to closure, which is the state it was in on the way out, so the closure checklist and the report dating panel are all still there and it can be closed again when the correction is booked. The reopening appears on the engagement timeline and on the audit trail, and the reason the engagement was closed for the first time is kept rather than overwritten. An engagement that was terminated for cause, terminated for convenience or cancelled cannot be reopened: those are contractual positions rather than delivery states, and resuming after one is a new engagement or a settlement recorded against the old one.

Why is the milestone slip chart empty on an engagement that plainly has slipped?

Two reasons, and the chart says which one it is looking at. It draws stored readings rather than the plan as it stands today, so an engagement whose readings have never been taken has nothing to draw: press Take a reading on the plan tab, or wait for the scheduled pass. The other reason is the baseline. A milestone is measured against the date the current baseline froze for it, so a milestone the current baseline never covered is skipped rather than being reported as on track. Capture a baseline first, and the reading afterwards will cover it.

A benchmark will not attach to a deliverable. What is missing?

The competition-law review. A peer comparison is a comparison against the client's competitors, and where the metric is a price or a cost, circulating it is a serious matter in most jurisdictions, so the review is required before the exhibit can enter a client-facing deliverable and again before the document carrying it can be released. Somebody with admin rights records it on the benchmark register, on the structuring tab, with a note saying what was checked and what was concluded. Note that editing the metric definition, the peer set, the data vintage or the client value withdraws a review that was already given: the exhibit that was cleared and the exhibit as it stands are no longer the same one.

Can I watch the delivery portfolio without opening the module every morning?

Add the Client Delivery widgets to your Home board. Open the Dashboard, choose Add widget, and search for engagement portfolio health, engagements at risk, RAID heat, information requests overdue, actions due, or approvals waiting. Two limits are worth knowing before you rely on them. The engagements at risk list is drawn from the twenty most recently updated engagements, and where more than that are red or amber the widget states the firm-wide figure underneath rather than letting the shorter list stand for the whole portfolio. The RAID counts come from one page of the firm-wide register, and the widget says so when that page was full. Every widget reads the same register as its own screen, so open the register whenever you need the rows behind a number.

Why can a colleague not add the Client Delivery widgets to their board?

Either their workspace plan does not carry Client Delivery, in which case the widgets are not offered in the library at all, or they hold the guest role. Guest is the client portal role, and the API refuses it every Client Delivery read, so offering a guest one of these widgets would place a permanently failing tile on their board. Member, admin and owner all see the full set.

Why will Atlas not let me mark a contract obligation as met?

Because the clause records the evidence it demands and nothing has been attached against it. Enter the identifier of the attachment that proves the obligation was satisfied and the control becomes available. The rule exists so that a met clause means a document exists, rather than meaning somebody remembered doing it. If the obligation genuinely no longer applies, waive it instead and write down why: a waiver is a decision somebody owns, and it is kept on the audit record with the reason.

Atlas drafted a status report for me. Has it been saved?

No. A draft sits on the Assistant tab of the engagement as a proposal and changes nothing until you accept it, and you accept named parts rather than the whole. Take the executive summary, leave the rest, and only that field is written. A field you accept is marked on the report as one nobody has been over yet, and the mark comes off as soon as you edit it. If the drafting is wrong, decline it: the declined proposal is kept, with what it said, so the firm can see how often that happens.

What leaves Atlas when I ask for a draft?

The engagement content the capability needs, and nothing else. For a status report that is the reporting period, the traffic lights, the open register items at high or severe, the milestone and thread counts and last period plan; for minutes it is the transcript and the agenda; for a deliverable pre-check it is the deliverable text and its acceptance criteria. It goes to the model provider your firm has configured under Settings, AI providers, and it goes nowhere until an administrator turns AI assistance on for Client Delivery, which is off by default. A draft built for a client audience leaves out anything marked confidential or not marked for the client, including the commercial figures unless your firm shares the budget with clients. The prompt itself is not kept: what is stored beside the draft is a digest of it, which is enough to prove two drafts came from the same state and not enough to reconstruct either.

Why can I not type a risk into the status report?

Because the key risks on a report are selected from the live risk register rather than written in the report. A report that can name a risk in its own words will eventually name one the register closed weeks ago, and when the two disagree the client believes the report. If the risk you want to name is not on the register, raise it on the register first and it becomes available to pick. Closed items stay visible in the picker, with their status, so you can see what happened to something you highlighted last week.

The client cannot see a report I issued. Why?

A report reaches the client portal only when three things are true at once: it has been issued, its audience is the client rather than the engagement team, and it is not marked confidential. The composer shows you which of those is missing: where the report will not reach the client, the preview beside it says so in those words instead of showing you a document nobody receives.

How do I decide whether a change or a report goes to the client?

Every register that can put a record in front of a client uses the same pair of controls, and it is the only way a record becomes client-facing. On a change request the pair sits on the screen for that change, under Who can see this change; on a status report it sits in the composer, under Who this report is written for; on the risk register it sits in the manage panel of the row. Sharing takes one click. Withdrawing asks you for a sentence first, because taking something back from a client is the half somebody will be asked to explain later, and the sentence is cheapest to write at the moment it is still known. Both halves are recorded on the engagement timeline and in the audit log with your name against them. There is no other way to change it: the ordinary edit screens refuse the field outright, so the register can always answer who decided to show a client something and when.

Why will Atlas not let me share this change or this report?

Because in that state the client would see nothing whatever the marking said, so Atlas refuses rather than reporting a success that did nothing. A change request still in draft is refused: a draft is the firm working out what to propose and the portal never shows one, so submit it into the approval chain first. A status report is refused while it is marked confidential, and while it has been replaced by a later report. In each case the control is inert and the reason sits beside it, rather than the click producing an error. A status report can be marked for the client while it is still a draft, which is the normal way round: the marking says who you are writing for, and issuing is what sends it.

I made a mistake in a report the client has already received. Can I edit it?

No, and that is deliberate. An issued report is the document the client is holding, so editing it would leave the record disagreeing with what they have. Use Replace with a corrected report on the composer. Atlas keeps the issued report as it was sent, marks it as superseded, and creates a replacement draft for you to correct and issue, which is the only version of a correction a client can audit.

Why can I not start work on this engagement?

Open the engagement and read the Readiness panel. It lists every reason at once: an acceptance decision that has not been taken or has expired, a screening check that is outstanding or whose clearance has lapsed, a legal instrument that is not executed, or a quality review that has not happened. Each line says exactly what is missing. Those reasons are enforced as well as displayed: while any of them stands, the move into Mobilising is refused and the refusal repeats the same list. That move runs through the API today, because the lifecycle has no screen control yet. A waived check does not appear, because a waiver is a decision on the record, and an optional check never appears at all.

What happens when a change request is approved?

Four things happen together. The approved change value rises by the assessed cost, the end date moves by the assessed days, a new baseline is captured with the change request recorded as its authority, and cumulative drift is recomputed. The contract value is never touched, so the signed number stays readable years later.

What is cumulative drift, and why is it measured against the original?

It is the total of every approved change, as a percentage of what was originally signed. Measuring against the current baseline resets the number every time the baseline moves, so an engagement that has been rebaselined four times reads as barely changed. The original is the only fixed point, and crossing the threshold raises a steering committee review once rather than repeatedly.

Why does the status report make me pick risks from a list?

Because a report that can name a risk the register has never heard of, or one closed three weeks ago, will eventually contradict the register, and when it does the client believes the report. Selecting from the live register means the two cannot disagree.

Why does the deck progress say pages evidenced rather than a percentage?

A completion percentage is heard as nearly finished when what is nearly finished is the outline. A page counts as evidenced only when it has an answer written on it and a completed analysis behind it, so fourteen of twenty-two evidenced is a fact rather than an impression.

Can I add a working paper after the file is locked?

Yes, and it is recorded prominently. Refusing would mean the paper lives in an email instead, which is worse: the evidence exists and the file does not know about it. Atlas requires who added it, why it is being added after assembly closed, and who approved that, because those are the questions an inspection asks first.

Which exports can go to the client?

The risk register, change log, deliverable register, plan and status history all have a client edition, filtered to what is marked for the client. The workplan, the acceptance pack, the workpaper index and the economics summary do not, and asking for a client edition of those is refused rather than downgraded.

Why does the completion estimate name a formula?

Because the two in common use disagree by a wide margin on exactly the engagements where the number matters. One assumes the overrun was a one-off, the other assumes it continues. Both are defensible, and recording which one produced the figure is the only way a reader can tell what they are looking at.

What does a client actually see in the portal?

Twelve surfaces, each on its own address under one tab rail, and a thirteenth where the firm turns it on: an overview that summarises the rest, the actions assigned to that person, the milestones and how far each has progressed, the information requests marked visible to the client, the deliverables marked for the client audience, the document library, the meetings whose minutes have been circulated or approved, the threads marked for the client audience that are not confidential, the status reports that have been issued, the change requests and the decision each one is waiting for, who is on the engagement from both sides, and four notification switches. The commercial summary is the thirteenth and appears only where the firm shares the budget with the client. The engagement name, its code and its single overall traffic light sit above all of them. The plan itself is never exposed: what the milestones screen carries is a title, a date and a percentage, and never the internal task, the owner, the effort or the float on the same row. A team member appears only where somebody marked them visible to the client, and with an address only where the firm marked that person shareable.

Why can I not score an assumption, and why does validating one leave it on the register?

An assumption has no probability axis. It is a premise the engagement is running on, and it either holds or it does not, so Atlas offers it no five-by-five grid: a heat map that mixed measured risks with beliefs would give you a colour that stands for nothing. What an assumption gets instead is validate and invalidate, with the evidence written alongside. Validating one leaves it live on the register on purpose, because an assumption that still holds is one the engagement is still exposed to and has to keep being revisited. Invalidating one closes it, because a premise that turned out false is finished and what happens next is a risk or a change request, raised from it.

Why does the heat band sometimes disagree with the number I expected?

The band is written by Atlas in the same operation as the score, and the screen shows you what came back rather than working one out. The bands over the 1 to 25 scale are deliberately uneven: 15 and above is severe, 8 to 14 is high, 4 to 7 is moderate, and below 4 is low. A four by four and a five by five are both drop everything, while the long tail below 5 is noise that should not colour a steering pack red. An issue is always scored at certainty whichever probability you pick, because an issue has already happened, and that is what lets issues and risks sort against each other on one heat map.

Can a client see our margin, our RAID register, or what we have written about their sponsor?

No, and not because a control is hidden. Nine surfaces have no portal endpoint at all: the acceptance file and its screening checks, the commercials, the stakeholder map, the RAID register, the working papers, the hypothesis tree and interview programme, the lessons learned, the workspace directory, and meeting transcripts. There is nothing to call, so there is nothing to filter incorrectly. The rows that are served are filtered inside the query rather than afterwards, so an internal row is never loaded into memory next to a client session on its way to being dropped.

How do we give a client access, and how do we take it away?

Two records. An invitation is issued for one person against one engagement and carries a token valid for fourteen days that can be used once. The access grant on the engagement is what actually opens the portal, it records who granted it and why, and accepting the invitation creates it. Taking access away means revoking the grant, and that ends the access everywhere at once: the next request is refused, a download link they already hold stops resolving, any live update stream in an open browser tab is dropped, and the session itself is ended so the token in their hands stops working immediately rather than lasting out its hour. Where it was their last seat, their guest membership is disabled too, which frees the seat against your plan. Revoking an invitation stops a token nobody has used yet. All four steps run through the API today: none of them has a screen. Every one of them is written to the audit record, and a revocation is also written to the engagement timeline.

Somebody at a firm has sent me a portal link. What is it for?

You are the client on an engagement, and the portal is the one place where the firm asks you for things and you answer. It shows what the firm needs from you and when, the actions that were agreed with you, the deliverables waiting on your decision, the minutes of your governance meetings, the threads you are part of, and the status reports the firm has issued to you. You can upload a file against a specific request, tell the firm a request does not apply and say why, mark an action complete, reply to a thread, and sign off a deliverable. Open /portal to see every engagement you have been given access to: if that is one, you are taken straight to it. You see those engagements and nothing else, and the firm sees a record of everything you did.

What happens when I sign off a deliverable?

You choose one of three answers: approve, approve with comments, or request changes. The last two need a short comment, because work sent back without a reason gives the team nothing to act on. All three need you to type your name before Atlas will accept the sign-off. Approving marks the deliverable accepted and records the moment. Requesting changes sends it back for revision. Either way the engagement record keeps the movement, the time and the account it came from, so what was decided and when stays legible long after the conversation is forgotten.