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 client portal your clients open at your firm's own web address, under the portal domain or on a domain you own, or at the /portal page of your Atlas address, with one page in the module that explains the whole of how a client is given access, what they will see once they are in, and what stays private
• 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
• A status report built from sections rather than one block of prose, each section carrying its own light, its movement since the last report, and whether the client reads it, so one report is written once and read by two audiences
• Sections edited in place with their own words, light, percentage and audience, and reordered so the report reads in the order the story is best told
• A section written complete in one step and bound to the workstream or phase it reports on, so the report and the plan name the same thing
• Every section names who owns it, chosen from the people in the workspace rather than typed as an identifier nobody knows. A section nobody owns says so in words rather than leaving a gap the reader has to interpret, and an owner can be changed or cleared from the same place, because a section whose owner has left the engagement and cannot be unset is a report that names the wrong person every week
• A deliverable shows who signed it off and against which version. That last part is the whole point: an approval is given for the version in front of the approver, so three approvals against version three say nothing about version four, and Atlas states plainly whether the deliverable is approved as it stands rather than leaving somebody to read a stale signature as current. A rejection is shown as a rejection with the reason beside it, and approved with conditions is its own answer rather than being folded into either, because the conditions are the part a reader needs
• The acceptance tab carries the instruments the engagement rests on: sixteen kinds of document from the master agreement to the penetration test report, each with where it stands and whether it is required here. Any required instrument that is not executed is called out on its row and counted at the top, because work running against an unsigned master agreement is the commonest way a firm discovers it has no contract it thought it had. Expired is kept apart from never signed, since one of them means the firm was relying on it until recently
• The portal can have a web address of its own, set up by an owner or administrator in Settings, Client Delivery. Under the portal domain a firm chooses a name of three to forty lower-case letters, numbers and single hyphens, checked for availability as it is typed, with names that read as part of the platform reserved; nothing is set up in DNS for it. A domain the firm owns, such as portal.yourfirm.com, is proven with a TXT record and pointed at the portal with a CNAME record, both shown on the screen with copy buttons; Atlas checks for them for seven days or at once on request, the Atlas team approves the domain, a secure certificate is issued, and owners and administrators are told in Atlas when it is live, refused or could not be set up. A firm can use up to three domains at once. While an address is live, invitations and emails link to it, links already sent keep working, and clients sign in on the Atlas sign-in page and are brought back to the firm's address automatically
• A client contact is invited into the portal from the people tab, chosen from the CRM contact register rather than typed in as an identifier nobody knows, or added in place with the address the invitation should go to when the client is not on file yet, and the contacts of the engagement's client are listed first. The invitation is sent to them by email, and the link is shown to you as well, because it is the only copy that exists and a contact with no address on record cannot be sent anything. The screen says which of those actually happened rather than reporting that an invitation is on its way regardless: sent and to which address, no address on the contact, no mail provider configured, or delivery failed. Beside it is the register of who has been invited, at what level, when it expires and where each one got to, and it never carries the token, because reading who has access is not permission to enter. A row that has not been accepted carries its own Revoke control. The access level decides what the client may do rather than what they see: a restricted guest reads everything shared but cannot approve, reply, upload or answer, and a guest can. A new invitation starts at the level the firm sets in Settings, Client Delivery, restricted guest unless it is changed, and can be limited to particular workstreams
• A thread records its first response, which is the moment a response-time commitment is measured against. The control appears only while the response is unrecorded and disappears once it is, because the first response is a fact about a moment rather than a field to edit
• An agenda item can say that a decision was actually made, alongside what the item decided. An item that was discussed and settled nothing is a real outcome, and a minute that cannot state it tells a board something untrue about its own sitting
• The people tab holds the whole team rather than only its access grants: everybody working on the engagement across the firm, the client and third parties, the share of their time it takes, and who is named as key personnel, which is a contractual promise rather than a label. Sharing a colleague's email address with the client is a decision somebody makes, so it is off unless switched on and never assumed by a form. Beside the team sits the register of subcontractors delivering under the firm's name, with the state of each contract, and a plain warning on any whose flow-down clauses have not been confirmed. That is the one that gets missed: the firm promised the client something the subcontractor never agreed to, and nobody finds out until the client asks for it
• Choosing a stakeholder on the stakeholder map opens what has actually been said to them and what came back: every conversation, the channel it happened on, how long it took, and where the person stood when it ended. That last part is why the log exists. An influence map updated separately from the meetings that moved it is a map nobody trusts, so the conversation and the position after it are recorded together. Nobody having judged where somebody stands is kept apart from having judged them neutral, because the two are different facts and only one of them is information
• Every RAID item carries its own history, which can be read: every status change, rescore, review, escalation and link, newest first, with who did it and the note they left. The same panel turns an item into another kind, offering only the changes that are actually allowed, from one declaration Atlas and the screen both read, so no control is offered that would then be refused. A decision converts to nothing and says so rather than showing an empty picker. The original is never deleted: it moves to superseded pointing at its successor, because a risk that quietly became an issue with no trace is how a post-mortem loses the thread
• The client purchase order is on the commercials tab: the order number, its value, how much has been drawn down against it and what is left. The headroom figure and the decision to warn are both Atlas's, taken against the warning percentage the firm itself set, so a firm that chose ninety five is not warned at eighty. An engagement with no purchase order value recorded says exactly that rather than showing nothing left, because a purchase order nobody raised and one that has been spent are different facts and only one of them is a problem. Value is drawn down or released with a signed amount and a note saying what it was for, rather than by editing a running total, so the record says what happened and not only what the number became
• The delegation of authority is on the same tab, with the question it exists to answer built in: for a decision of this size, who signs it. The bands say from what value each kind of decision, a discount, a write-off, a change request, a sign-off, an expense or a contract, needs an approver, and whether it needs two. A band with no upper limit says so in words, because a blank upper bound reads as missing data when it actually means every decision above the floor lands there. The chain is worked out by Atlas rather than by the screen, since an engagement band replaces the firm-wide band at the same threshold rather than adding a second signature, and two places computing that rule is how two screens come to disagree about who signs a write-off. A failed read says it failed and never renders as no bands, because no bands means nothing needs approval
• Access to the client systems is a register on the ways of working tab, which can be written to as well as read. It shows what each person was given, at what level, and the count that matters on an engagement that has ended: how many logins are still open. Closing a row requires the evidence that access was actually removed, a ticket, a screenshot, a confirmation, because asking somebody to remove access is not removing it and a register that accepted the request would record a closure that never happened. A row nobody has granted yet is marked apart from one granted and still open, since the first is not a risk and the second is the whole point of the list
• Document handling is worked from the working papers tab rather than living only behind the API. Each document says how it is marked, whether it may be printed, forwarded or downloaded, whether rights management and a dynamic watermark are applied, and when access expires. The release gate is the part that matters: Atlas refuses to release a document whose redaction layer is not flattened, whose redaction nobody has verified, whose metadata is not scrubbed, that carries inside information with no confirmed insider list entry, or that discloses a benchmark with no competition-law review. Every outstanding item is listed at once rather than one at a time, because a reviewer told about one blocker, who fixes it and is then told about the next, stops trusting the check. The list of blockers on the screen is the same list the gate enforces, computed in one place, so the two can never disagree. Verifying a redaction is offered while the layer is unflattened and says so rather than disappearing, because why it cannot be done yet is the thing worth knowing. A released document can be recalled with a written reason, and it still says it was released, because a document that was never sent and a document that was sent and withdrawn are different facts and only one of them is true
• The working paper file's own lifecycle: check the seal against the papers in it, clear the review notes, place and release a legal hold with the reason on both, record what a regulator was shown, and destroy the file at the end of its retention
• A named distribution list on each report, and a send that skips anybody who already received it rather than sending twice
• 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 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 storyline on the structuring tab, written answer-first: every page carries the sentence it exists to prove, and a page without one is called out however far along it claims to be. Pages nest, so the shape of the argument is visible, and they can be reordered within a branch because the order two reasons are read in is part of the case. A page becomes evidenced by passing a check rather than by somebody deciding it looks finished, and the refusal names what is missing
• A workplan on the structuring tab: the analyses that will settle the argument, each one naming the exhibit it should produce before the work starts, because an analysis with no named output is the one that runs for three weeks and yields a folder of spreadsheets. An analysis is planned, started, recorded as blocked, or finished. A block will not send without a written reason, since a blocked analysis nobody explained tells a manager work has stopped and gives them nothing to unblock, and the reason is shown on the row rather than filed away. Finishing requires the finding and the implication together: what the numbers said without what follows from it is a chart nobody can act on. A finished analysis is offered no further controls, because every one of them would be refused
• An interview register on the same tab, with consent recorded on screen. An interview is not attributable until somebody records that the person agreed to be named. The two permissions are kept apart, because agreeing to be interviewed is not agreeing to be quoted by name in a report the client reads, and one tick for both would claim a permission nobody gave. Everyone is named on screen through the citation Atlas computes from the consent actually recorded, never through the name on the record, so a person who has not agreed appears as their anonymous handle everywhere. A refusal is recorded as a refusal, since somebody asked and told no is a different fact from nobody having asked, and consent stays editable after the conversation closes, because a person can change their mind and there has to be somewhere to honour it
• The hypothesis tree can be corrected and restructured, not only planted and concluded. A node is reworded, and a branch is moved under a different question or up to the top of the tree, which is a real destination rather than the absence of one. A node is never offered itself or anything beneath it as its own new parent, since that would detach the whole branch from the tree. Atlas repaths every descendant and reports how many rows it touched, so a move that took one node instead of the branch is visible rather than silent
• A source register on the structuring tab, where every citation carries an Admiralty grade read as a pair (how far the source is trusted, and how likely this particular claim is), what corroborates it and what contradicts it. The weakest grade in the register leads, because a finding is only as reliable as its worst source, and a retraction marks the row rather than deleting it so anything already citing it can still be traced
• 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 engagement overview can move the engagement. From it you can put the engagement into acceptance, mobilise it, hold it, close it, archive it and bring it back, set any of its seven traffic lights, and decide a phase gate. Only the states the engagement can actually move to are offered, from the same table the server enforces, so nothing is offered that would be refused. A pipeline engagement is never offered mobilisation, because acceptance is the gate where independence, conflicts and credit are cleared and a firm that bills before clearing them has a problem no status field can fix. An engagement that has closed, been cancelled or been terminated is offered nothing and says so, rather than showing an empty row that reads as a permission problem. Every traffic light change carries a written reason and the control will not send without one, because a rating that moved with no stated cause tells a steering committee that something changed and gives them nothing to act on. Only the lights somebody actually touched are sent, so setting the schedule light cannot silently restate the other six over a change another person made in the meantime. Archiving asks twice and says in words what it does, since it takes the engagement out of the working register while keeping every record on it, and bringing it back is one click
• 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
• A deliverable has an acceptance surface as well as a review ladder. It shows what is blocking acceptance, and lets you write the criteria the deliverable has to satisfy, assess one, waive one, freeze the version that was sent, ask the client to sign, and record a reviewer's verdict. Every blocker is shown at once, because a reviewer told about one blocker, who fixes it and is then told about the next, stops trusting the check. An acceptance criterion has three states and not two: met, not met, and nobody has looked, and the third is the one every criterion starts in, so a screen that rendered it as a pass or a failure would be reporting a judgement nobody made. A waiver is its own fourth state and requires a written reason, because that is the difference between a criterion somebody decided to accept unsatisfied and one nobody assessed. A deliverable with no criteria at all is called out rather than shown as an empty list, since it can be signed off against nothing in particular and that is how a dispute about what was delivered begins. A reviewer chooses from five outcomes, because a real review mostly reaches approved-with-comments or changes-requested and collapsing either into approve or reject throws away the only useful thing the reviewer said, and a round that has been answered is not offered for re-deciding: the way to revisit a review is to request another round
• 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
• A change request is decided on its own screen. Every decision that makes change control change anything is taken there: assessing the impact, sending it to the board, deferring it, withdrawing it and marking it implemented, as well as whether the client may see it. The screen offers only the moves the change is actually allowed to make from where it stands, taken from the same table the server enforces. A submitted change is never offered a shortcut to the board, because assessing the impact is a required stop rather than an optional one: a board deciding without an assessed impact is guessing, and the guess becomes the commitment. Approval and rejection are not offered as buttons at all, because neither is one person's decision to take; they are the outcome of the chain, which is shown grouped by step so it is visible which approvers are blocking today and which are waiting on them. A veto is marked apart from being required, since a veto that can be outvoted is not a veto, and the conditions an approval was given on are recorded with it, because an approval given on terms with the terms unrecorded is an approval nobody can hold anybody to. Abstaining and delegating are offered alongside yes and no, because both are real answers and a form that omits them collects a yes from somebody who meant to abstain. The screen also reads the one change request by its own identifier rather than looking for it inside the register, which is capped and filtered, so a change past that cap is still found at an address that names it.
• 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
• That screen can record what it reads. It records a screening result, waives a check, opens the file, puts it into review, records the engagement quality review and takes the decision itself. The decision sits above the checks, because whether work may begin is the question and the checks are how it is answered. A file that has not been put into review is offered no decision at all, since the server requires that step and a control that skipped it would produce a refusal at the moment somebody thought they had decided. Accepting is still offered while checks are outstanding, and the control says how many: a partner may accept over the firm's own checks and often must, and a control that disappears when the answer is inconvenient teaches people to work around the system, but it must never happen quietly. Accepting with conditions will not send until the conditions are written down, because a condition nobody recorded cannot be checked off later. An accepted file states its expiry, since acceptance is not permanent and a clearance that has lapsed is the most dangerous thing this screen could fail to say
• The list of check statuses the interface knows is held to the database by a test. A required check that came back cleared with findings, meaning it cleared and somebody noted something, reads as satisfied and is marked so that the finding gets read. A check marked not applicable also reads as satisfied, because neither has any onward state.
• 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
• The commercial register is the other half of that screen. The rate cards, budgets, expenses and billing milestones the economics figures are computed from are worked from one tab in the order the money moves in: a fee is agreed as a milestone, work is budgeted against it, costs are claimed, and rates convert hours into both. Every move a fee or a claim can make is offered from the same table the server enforces, so the screen never draws a button that would be refused, and a state with no moves left says it is settled rather than showing an empty cell. A write-off is recorded beside the amount rather than reducing it, because what was agreed and what was recovered are different facts and replacing one with the other erases the agreement. Cost rates stay hidden until somebody asks for them, since the gap between what a grade costs and what it bills is the firm's margin
• Two things a person notices before they notice a feature. A screen that is still loading shows the shape of what is about to appear rather than a line of text saying it is loading, so a reader has something to scan while they wait. And a failure inside one tab of the client portal does not take the whole engagement with it. The error boundary of the portal sits inside the engagement shell, so a failure in one tab, such as deliverables, leaves the tab rail, the engagement name and the branding in place.
• A deliverable in the client portal has its own address. A client sent "please sign this off" with a link arrives on the deliverable itself, rather than on a list that is read a page at a time and where the row has to be found. The screen reads the one deliverable rather than searching pages for it, carries the same three sign-off decisions the list offers so a client meets one control rather than two dialects of it, and adds the description, which the list has no room for: signing off is a contractual acceptance and the decision should not sit beside only a title and a file. It says how many versions there have been without saying what changed between them, because the history of internal revisions is not the client's to read. A deliverable the client is not scoped to and one that does not exist give the same answer, deliberately, since the pair would otherwise reveal which identifiers exist on an engagement they are only partly admitted to
• 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 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. The export menu offers exactly the artifacts that can be produced: 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.
• 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 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 of twenty engagement archetypes, from strategy advisory and technology implementation to post-merger integration, cost optimisation, cybersecurity assessment and restructuring, each seeding a new engagement with a phase structure, workstreams, deliverables with what a client accepts them against, a RACI, risks worth starting from, a meeting cadence, information requests, a closure checklist and the acceptance checks the work requires
• 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 wall crossing is approved by an account, not a name: the approver must be a current owner or administrator of the workspace, chosen from the directory, and must not be the person crossing. Nobody can record their own crossing, whoever they name as approver
• 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 raised without choosing where it applies hides the engagement itself from the people it walls off, as well as its portal and its search entries. The people a barrier excludes cannot open the barriers screen for that engagement either, so the wall is not readable by the people on the wrong side of it. 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, so a code name hides nothing on screen
• A deliverables screen on each engagement that lists what the engagement owes, opens the review rounds held on any one of them, and shows the checklist each round was performed against. A review recorded only as an outcome and a comment box says a review happened; the question asked afterwards is never whether one happened, it is what was looked at, and the checklist is the only part of the record that answers it
• Every checklist question is answered yes, no or not applicable, and not applicable is a real answer rather than a way of skipping the question: asked whether revenue cut-off was tested, not applicable on an engagement with no revenue is correct and complete, while no is a finding. A question nobody has reached stays visibly unanswered rather than defaulting to a pass
• The outstanding must-fix count is recomputed from the answers on every write rather than taken from whoever is writing, and the confirmation that review notes are cleared is refused while it is above zero, recording who confirmed it and when. A count somebody types is a count somebody can type zero into, and a gate nobody signed is a gate somebody moved
• 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
• The library screen lists every playbook the workspace can start from, its own and the built-ins together. Once there are more than two it offers a search across the name and the description and a filter by the kind of work, and the filter lists only the kinds the library actually holds so no choice returns an empty screen. It says how many of how many are showing, and a search that matches nothing says so and offers to clear the filters rather than looking like an empty library
• 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 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 many service lines: strategy advisory, technology implementation, managed service, internal audit, regulatory remediation, due diligence, transformation programme office, advisory retainer, staff augmentation, training, post-merger integration, cost optimisation, cybersecurity assessment, restructuring and more. 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
• Ramp curves for people joining the engagement, holding how productive they actually are week by week. A new joiner is not fully productive on day one, and modelling them as a flat full-time equivalent is why plans are wrong. Past the end of the curve the last value holds, because somebody who reached full productivity in week four is still fully productive in week forty. Handover defaults to unbillable, since clients almost always refuse to pay for it
• A data disposition register recording what happens to every dataset at the end, where the data actually is, and what the client instructed. A destruction cannot be certified where the disposition lists a backup among its locations and the destruction does not cover it, because a certificate covering only live storage certifies something untrue while the data sits in a backup for another ninety days
• Where the client instructs destruction and the firm is separately required to retain, both cannot be done. The conflict is recorded as a conflict and blocks the certification until a legal basis is written down, rather than being resolved by a judgment made under time pressure on the last day of the engagement
• A tax position on each engagement covering which entity supplies whom from where, the value added tax treatment, any electronic invoicing mandate, and the withholding position. Invoicing itself stays out of scope: these are the policy-level facts whose absence lets a delivery team create a tax problem without knowing it
• The position reports what it is still missing on every reading rather than only on the day it was entered, so a rule change applies to everything already recorded. The gap worth reading twice is withholding tax with no gross-up clause: without one the firm is paid net of the withholding, and the withholding is a discount nobody priced
• A permanent-establishment day watch per jurisdiction, where the day count is derived from onsite time entries rather than remembered, and counted as distinct calendar days so that three entries booked against one day is one day on the ground. The warning has to be set before the threshold, because warning on the day it is crossed is warning after the fact, and a permanent establishment created by an unwatched day count is a seven-figure surprise
• A reliance register in both directions. Outward, every third party relying on the engagement work is a row rather than a filed letter, so the question of who can sue the firm over this engagement has an answer. The aggregate cap across all relying parties is summed before a letter goes out and the letter is refused if it would breach it, because caps set per party and left uncapped in aggregate are how a firm discovers one letter at a time that its exposure is unlimited
• Drafting a letter is separate from issuing one, because a letter drafted and never sent creates no exposure, and refusing to draft it would push the drafting outside Atlas, which is where the register stops knowing about it. A letter stating no aggregate cap at all is issued rather than refused, and the register says so on its face: an uncapped aggregate is what this exists to make visible
• Inward, work the firm relies on from a valuer, actuary, tax specialist or another firm cannot be accepted into the firm own work until the evaluation of it is written down. Accepting a specialist conclusion without evaluating it is forwarding their report rather than relying on it, and where the reliance is disclosed in the report the specialist has to have consented to being named
• A benchmark register where every metric carries the definition of what it actually counts, required rather than optional. Definitional mismatch is the commonest benchmarking error: cost per order means four different things across four companies, and a comparison of four different things looks exactly like a comparison
• A benchmark whose peer set names its members cannot be released to the client until somebody has reviewed it for competition law, because sharing a named peer set, or figures precise enough to identify its members, is how a benchmarking exercise becomes an information exchange between competitors. An aggregate that names nobody is released without one, since a gate that fires on everything trains people to click through it
• An expert network call register, because expert calls are the highest-compliance-risk routine activity in consulting and diligence and the one that produced criminal prosecutions. Every call records who was spoken to, through which network, under what clearance, and whether material non-public information came up
• Pre-approval means before. A call cannot be recorded as held without a prior approval, cannot be approved by the person who asked for it, and cannot be approved after it has already happened. Approving after the fact would leave a register that reads as compliant while the ordering was reversed, which is worse than no register
• A call carrying any compliance flag cannot be held until a chaperone is named. The flags are the cases where the conversation can go wrong without the participants noticing: a current employee of an in-scope public company, of the client competitor or of a live acquisition target, a government official, a regulator employee, somebody under a restrictive covenant, or a clinical investigator on an ongoing trial
• The annual cap on calls with one expert is counted from the calls already held rather than taken from whoever is booking, and a request past it is refused when it is made rather than after the expert time has been paid for. Payment is always through the network, never direct, and recording defaults to prohibited
• Sources carry Admiralty grading: reliability A to F for the source, paired with credibility 1 to 6 for the particular claim, so a source reads as "B2". Grading the source alone says nothing about the claim, which is how a reliable outlet speculative piece gets cited as fact. Sources also carry an archived copy, the date the data is actually from as distinct from when it was published, the identifiers of what corroborates and contradicts them, and a retraction flag
• A regulatory obligation register beside the contract one, on the same tab, because a delivery lead reads what this engagement is obliged to do as one question. A library seeds the obligations a regime lands on the engagement, covering digital operational resilience, data protection, health information, financial-services outsourcing, artificial intelligence and United States federal contracting. Clocks are counted in hours rather than days, because the tightest of them is four hours and a day is the wrong unit to round it to. What is due leads the panel and includes anything already overdue, since a forward-only window hides exactly what needs acting on today
• An obligation whose regime demands evidence cannot be marked met without the document, because an inspection asks how a duty was discharged and the answer is a file rather than an assertion. Waiving one requires its reason, because a waiver with no reason reads on the record exactly like an obligation nobody did. An obligation the library does not carry can be recorded by hand, so the register never sends anybody back to the spreadsheet it replaced
• A health score stored with the measures behind it and the weight each one carried, so it can be argued with rather than only quoted. A measure nobody could take gives its weight to the measures that were taken rather than scoring zero, which is why a young engagement reads as not yet measurable instead of red. Milestone trend keeps one row per milestone per reporting date, because a plan holding only today forecast cannot tell a milestone that slipped a week every month from one that slipped a month once
• A client contact admitted to the portal can be scoped to particular workstreams, and every portal read honours that scope: the deliverables, the information requests, the meetings and the threads all narrow to what that person was admitted to. An unscoped grant sees the whole engagement, which is what every grant means unless somebody narrows it
• Revenue recognition is recorded as events rather than derived. Eleven things can make a fee earned, from a milestone accepted to a deemed-acceptance window elapsing to a termination, and each is written down with the date it happened and the reasoning behind it. An event dated in the future is refused, because revenue cannot be recognised on the strength of something that has not happened. A billing milestone points at the event that made it recognisable, so the accounting date can be defended a year later rather than recomputed from inputs that have since moved
• An onerous contract provision on the engagement itself, raised the moment the unavoidable cost of finishing exceeds the benefit of doing so rather than at year end. Releasing one requires a reason in exactly the way raising one does, and the amount is cleared on release so a released provision never reads as a live one
• An expense carries the disbursement-versus-recharge distinction and the test that decides it. The two are identical on a bank statement and different in tax law: a true disbursement is paid as agent for the client and sits outside VAT scope, a recharge is the firm own cost passed on with its VAT. Whose name is on the supplier invoice is recorded rather than inferred, along with whether the client authorised it in advance, whether it was passed on at cost, and whether it is separately itemised. Carbon is recorded alongside the money, because clients increasingly ask
• Planned capacity counts what people actually contribute rather than what was asked for. A staffing request can name a ramp curve, and the week-by-week roll-up multiplies allocation by that week productivity, so a joiner in week one counts as the third of a person they are. A request with no curve counts in full, so attaching one only ever makes the figure more honest
• A transition plan carries the staff-transfer position. Where employees transfer with the service, consultation is mandatory and employee liability information is due twenty-eight days before, so the plan warns when consultation is not recorded as complete, when the liability date is missing, and when it has already passed. Every plan is warned about having no rollback, because a transition with no way back is a one-way door
• A model risk register on each engagement, because a spreadsheet error in a board deck is a career event and, where the client is a financial institution, the model inherits their own model risk obligations. Every model carries the tier that decides how deeply it is validated, what it is known not to be able to do, and the checks that were actually performed rather than the ones that were available
• Tier 1 is the deepest validation and the only tier that claims independence, so a tier 1 model whose named validator is also its developer is refused rather than recorded with a warning. Tier 2 and tier 3 allow the same person, because a small model built and checked by one person is honest as long as nobody calls that an independent validation
• A model cannot be approved for use until its validation has passed, and the approval has to name the purposes it covers. Passing with findings is a pass, because real validations find things and treating that as a failure would push people to record none; an approval with no stated purpose is the one that lets a scenario model written for one question carry a board decision it was never built for
• A language-model-based model cannot be approved until its hallucination controls are written down. Every other model type fails visibly and this one fails fluently, so the disclosure is the only control the reader has, and human review is on by default rather than off
• 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. 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 others
• 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, and at the firm's own web address where one is set up, with its own shell: its own sidebar of portal sections, 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. Each surface is its own address, so an email can link to the exact page it is about: an overview that summarises the rest, analytics, 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, the risks, issues and decisions the firm chose to show, change requests, who is on the engagement from both sides, the commercial summary where the firm shares it, and the notification switches.
• 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. The portal has no route for the acceptance file and its screening checks, the commercials, the stakeholder map, the working papers, the hypothesis tree and interview programme, the lessons learned, the workspace directory, or meeting transcripts. The RAID register is served only as the risks, issues and decisions the firm marked visible to the client and not confidential. 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, on both sides. Opening one in the portal 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. On the firm side the thread screen shows the same conversation with every post marked as visible to the client or internal, and the team answers there, for the client or as an internal note; the owner of the thread is told when a client replies. A thread reaches the portal only where it is shared with the client 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 share control on the file list of an information request shares one 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. 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 back to draft instead
• An invitation is issued for one person against one engagement, and the token it carries lasts fourteen days unless the firm sets another period, 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
• The portal is reached by a signed-in client and by nothing else. A personal access token or an OAuth token is refused on every portal address, so a credential copied out of a script cannot stand in for the person the seat was given to
• 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, and each one decides whether an email is sent. A status report reaching the portal, a deliverable or minutes or a change waiting for their approval, a firm reply in a thread they can read, and an overdue request or action they owe, once and then weekly, each send an email signed with the firm name and linking to the page it is about. Nothing is sent while the portal is off, a read-only seat is never asked to approve, and a seat that has never touched the screen has every switch on. 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, tagline, accent colour and logo 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. A logo uploaded there is stored and served to every client. Every email the portal sends a client is signed with the firm name
• 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 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 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 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. 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. The screens that gather work across the whole firm are the RAID register, the meetings, the information requests, the actions, the approvals and the exports. 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 firm-wide registers points here.
• 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. Some 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
• A linked project on each engagement, chosen on the Overview tab. It lets the plan adopt the project's tasks, lets a plan row be given a task, and lets the project's risks be imported into the RAID register. Until a project is linked, those actions are disabled, each one says why, and each points back to the Overview
• AI drafting that a workspace turns on deliberately. It is off until an owner or an administrator turns it on in Settings, Client Delivery, and it needs a model provider. Every draft is a proposal, and nothing reaches a register until a person accepts named parts of it

• A portal invitation can be accepted for fourteen days unless the firm sets another period, from one to thirty, in Settings, Client Delivery, and then stops working, so a link that goes astray has a limited life. An invitation not yet accepted is revoked from the invitations panel, and a client who has accepted is removed from the access register on the same tab. A client who accepts holds a guest seat on your plan for as long as their access lasts, and withdrawing the access releases it.
• A portal opens only for a signed-in account, so a copied link on its own reads nothing. A client who has no account creates one with the address the invitation was sent to, and the invitation then continues on its own. Atlas reports what actually happened to each invitation rather than assuming it arrived: delivered to an address, no address on file for that contact, this workspace not configured to send mail, or the mail provider refused it. In the last three the link is shown on screen so the firm can pass it to the client through a channel it trusts.
• A register that cannot be read says so, and never says it is empty. Where a list, a total or a warning strip could not be loaded, the screen shows a failure with a control to read again, and it withholds the empty state rather than telling you nothing is overdue, nobody holds access or no wall crossing is open. Treat those alerts as unanswered questions rather than answers: the weekly capacity total is left blank rather than shown as zero for the same reason, and the risk extraction on the assistant tab is withheld outright when the threads it would read could not be loaded, because it would otherwise return a confident answer drawn from nothing
• 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 is not classified is not reshaped: every tab shows.
• 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 stays 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, the status reports, the threads, the deliverables and the meeting forums 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. 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 raised without naming its points covers the engagement records, the portal and the search index, so by default it hides the engagement from the people it walls off. 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.
• A review checklist is only as good as the questions somebody put on it. Atlas does not supply them and does not require any: a review with no checklist is allowed and says so on its face, so a clean review-note gate on a review that was never given questions means nothing was asked, not that nothing was wrong.
• Confirming that review notes are cleared is refused while any question is answered no. It is a refusal rather than a warning, because a deliverable going to a client over an unresolved must-fix is the failure the gate exists to prevent. The way past it is to resolve the finding and change the answer, not to override the gate.
• 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 and, where it is set up for it, by email. The delivery record says on each attempt what happened, 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 outstanding-disposition list only counts instructions that leave something to do. A dataset the client asked to be retained under the contract or under the law is not outstanding, because including it would make the list never empty and therefore never read.
• The permanent-establishment day count only sees time entries that record where the work was physically performed. Time with no onsite country is treated as remote or home-country work and counts towards nothing, so a watch reading zero means nobody has been recording location, not necessarily that nobody has travelled.
• The reliance exposure figure is summed by the server rather than in the interface. These are the numbers a firm is sued for, and adding them through an ordinary floating-point number would round them in the direction of the total looking smaller than it is.
• Releasing a benchmark is a decision taken at release rather than a consequence of recording it, because whether the peer set identifies anybody can change after the benchmark was first entered. Editing a peer set to name its members puts the benchmark back on the list waiting for a competition-law review, even if it was reviewed before.
• An information incident on an expert call is recorded as a fact without asking the person who heard it to judge it, and the compliance review that closes it is a separate act by a separate person. Conflating the two would let whoever heard the information close their own incident, and an incident recorded and never looked at is worse than one nobody wrote down, because the record proves the firm knew.
• The model register only knows the models somebody entered. An empty register means nobody recorded one, not that the engagement built none, so a clean tier 1 panel is only as trustworthy as the recording behind it.
• Retiring a model does not delete it. A board paper that cited it still exists and somebody will eventually ask which version produced the number, so a retired model leaves the register view by default and stays readable when asked for by name.
• 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 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 each have a screen on the engagement people tab, and the same operations are available through the API for a firm that automates them.
• 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, because the module has no engagement-wide file list to put the control on. The library therefore 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 back to draft. The decision is also recorded as an approval on the engagement. The approval carries the decision, the typed name, the comment, the account the decision came from and a hash of the content, so approving and approving with comments can be told apart afterwards. The address and browser of the signer are not captured.
• 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.
• Linking a project needs permission to edit the engagement. The project must belong to the same workspace, must not be archived, and must not be a personal project. It can be changed or removed from the Overview, but not while plan rows hold tasks of the current project, because those rows would then point at a project the engagement no longer names: release those tasks from the plan first. Every link, change and removal is recorded in the audit log.
• Turning on AI drafting sends engagement content to the model provider the workspace uses. Only an owner or an administrator can change the setting, and the change is recorded in the audit log. While it is off, or while no model provider is available, the draft actions on the Assistant tab are disabled and say why, and the same refusal applies to anything that calls the draft routes directly. An engagement behind an information barrier is never sent, and neither is a thread marked confidential.

1. 1Open Client Delivery from the sidebar, or press the command key and K and search for Engagements.
2. 2To give a client access to their own view of an engagement, read Client portal in the sidebar under Client Delivery first. That page is the whole of the onboarding process in one place: what the portal is, what to confirm before inviting anybody, the five steps, every screen the client will be able to open, and what stays private whatever else is shared.
3. 3Then issue the invitation from the engagement itself. Open the engagement, go to its People tab and use the portal invitations panel. Choose the client contact, choose how much they may see, and issue. The restricted guest is the default and shows less than the guest, so widening access is a decision somebody makes rather than one that happens.
4. 4Check what the panel says happened to the invitation, and hand the link over yourself where it says the message could not be sent. Then withdraw access from the same panel whenever it is no longer needed, or when a link has gone somewhere it should not have.
5. 5If 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.
6. 6Every 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.
7. 7Importing 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.
8. 8Start 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.
9. 9The 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 is not refused for a field nobody asked you about. If your workspace has no clients yet, record one from that step without leaving the flow.
10. 10The 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.
11. 11Open an engagement and use the section tabs across the top. They are grouped into three. Run holds the overview, acceptance, scope, the plan, workstreams, responsibilities, ways of working, the RAID register, assumptions, the model risk register, expert calls and the assistant. Govern holds meetings, threads, information requests, change requests, status reports, contract obligations, follow-ups, information barriers, screening, reliance and tax. Deliver holds deliverables, structuring, working papers, stakeholders, people and handover, economics, commercials, revenue recognition, reusable assets, benefits, client voice, the sales handoff, data disposition, closure, the timeline, custom fields and imports. Anything the operating model does not promote is still one click away, under All surfaces at the end of the strip.
12. 12On the disposition tab, record each dataset with everywhere it actually is, including backups, and what the client asked be done with it. Certify the destruction when it has been carried out, saying which method was used and whether the backups were covered. The same tab holds the ramp curves for people joining.
13. 13On the tax tab, set a day watch for each jurisdiction the team travels to, with the threshold and a warning point before it. The count comes from the timesheets. The tax position below it records how the engagement is supplied and shows what the position is still missing.
14. 14On the reliance tab, record each third party relying on the work with the cap offered to them and the aggregate ceiling, then issue the letter. The panel at the top is the total the firm is exposed to across every letter issued. The same tab records work the firm relies on from outside, which cannot be accepted until the evaluation of it is written down.
15. 15On the expert calls tab, request the call with its network, expert reference and topic, and tick anything that applies to the expert. Somebody else then approves it, it is recorded as held afterwards, and if information came up on the call it is flagged there for compliance to review.
16. 16On the models tab, record each model with its type and its validation tier, record what the validation found, then approve it for the named purposes it may be used for. The panel at the top lists every tier 1 model still waiting for validation, which is the one question the register is asked.
17. 17On the structuring tab, write the storyline under the hypothesis tree. Start with ghost pages: a title and nothing else, so the team can argue about the story while it is still cheap to change. Give each page its governing thought, the one sentence that page exists to prove, and write it as the answer rather than as a topic. Move pages within their branch until the argument reads in the right order. When a page has its governing thought and a completed analysis behind it, ask for it to be marked evidenced; if it is refused, the reason says which of the two is missing. The panel leads with how much of the story is evidenced and how many pages still have no governing thought, which is the number to read first: a deck can be almost entirely drafted and still say nothing.
18. 18On the structuring tab, below the hypothesis tree, cite each source the argument rests on. Grade it twice: how far the source itself is trusted, from beyond doubt to cannot be judged, and how likely this particular claim is. The two are read together, so a usually reliable outlet making a speculative claim does not read as fact. Then record which other sources corroborate it and which contradict it. The panel leads with the weakest grade anywhere in the register, since a finding is only as reliable as its worst source. If a publisher withdraws something, record the retraction: the row stays on the register, marked, so everything already citing it can be found and corrected.
19. 19On the deliverables tab, open a deliverable to reach its review rounds. The newest round is shown first and the earlier ones are one choice away, which is how you compare what round two found against round one. Each round lists the questions it was performed against in the order they were asked, with how many are unanswered and how many were answered no. Answer each one yes, no or not applicable, then confirm the review notes are cleared. That confirmation is refused while anything is answered no, and the screen says how many are open rather than only that it will not proceed.
20. 20Open 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.
21. 21Work through the checks and the legal instruments. Check readiness at any point to see everything still outstanding.
22. 22Once acceptance is granted, build the plan and capture the original baseline.
23. 23Run 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.
24. 24Log risks and issues on the register, raise change requests when the scope moves, and record deliverables as they are submitted and accepted.
25. 25A 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.
26. 26Give the client access to the portal when there is something for them to do. Issue an invitation for one person on this engagement from the People tab, and grant that same person access to the engagement, which is what actually opens the portal for them.
27. 27Write 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.
28. 28Send 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.
29. 29At the end, assemble the working paper file, confirm the review notes are cleared, and lock it. You do this on the Working papers tab, where the file, its readiness check and its lock are all on screen.
30. 30Open 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.
31. 31Below 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.
32. 32Revoke 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.
33. 33To 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.
34. 34Export whatever the client or the reviewer needs from the Exports control on the engagement.
35. 35See who can read the engagement, and why, on the People tab. Every grant carries the reason it was given, because six months later an access review asks why somebody had access rather than who did, and a register that answers only the second is a list of names. A grant that names no workstreams admits its holder to the whole engagement, which the row says in words rather than leaving an empty cell that reads like a restriction. A grant whose expiry has passed is marked as lapsed rather than shown as current, and a grant somebody revoked stays on the register with the date, because the record that a person had access between two dates is exactly what an incident review needs and exactly what deleting the row destroys.
36. 36Record what the engagement is for on the Scope tab. Each objective carries the measure that says whether it was met, and Atlas will not let you save one without both, because an objective with no measure is an intention and a closure report built on intentions cannot say what was delivered. An objective shows its target and its reading separately, and one nobody has measured says so rather than showing a target that reads like a result. Partly achieved is drawn as its own outcome rather than as success, because most objectives land there.
37. 37On the same tab, record what the engagement covers and what it explicitly does not. Both sides are shown together rather than one behind a control: the out-of-scope lines are the ones that settle an argument, and a register that files them out of sight files the evidence where nobody looks for it. A line that arrived through an approved change says so on the row, which is the difference between a scope baseline and a list somebody edited. A line that stops applying is kept on the record and counted below the register rather than deleted, because the question a dispute asks is what the scope said in March.
38. 38Write down how the two teams will work together on the Ways of working tab. Working hours, core hours, timezones, meeting cadence, how you communicate, response times, how decisions are taken, document and naming conventions, what ready and done mean, confidentiality, tooling, and risk appetite. Every field is prose rather than a picker, because these are agreements between people, and the moment they are modelled into structured fields somebody has to write an exception, such as "except at month end", into one of them anyway. Fill in only what you have settled: a field left blank is left off the record rather than shown as an empty row.
39. 39That record says in words whether it has been agreed or merely written. An agreement one side typed is a draft, and only a record both sides have agreed can be pointed at later, so mark it agreed once they have rather than letting the presence of text imply it. The record also says whether the client can read it in their portal.
40. 40Build the escalation ladder on the same tab. Each rung carries its level, who it goes to, what triggers it, and how long that rung has to respond before the next one is used. Rungs are read in the order of their level, so a ladder with a gap in it still works. The first time something stalls is a bad moment to invent one.
41. 41The one action a tab most wants you to take sits in the header beside the engagement name, and it stays there while you scroll. Raise a risk, add a deliverable, raise a change, start a thread, record a benefit: each is one control in the same place on every register, rather than a button somewhere below the list. Pressing it opens the form in the body, and the header control disappears while the form is open because the action has become the form. Twelve tabs deliberately have no such control, because they are readouts with nothing to create or screens whose actions belong to an individual row.
42. 42Print the minutes of a governed meeting with Print minutes, on the meeting itself. What prints is a document rather than the screen: who attended and who sent apologies, whether the meeting was quorate, the items covered and their outcomes, every motion with its tally and each vote by name, whatever was carried forward, and the record of the meeting. Minutes that have not been approved say so across the top of every page, and the foot carries the version and the moment it was printed. Use the browser print dialogue to save it as a PDF.
43. 43On a phone or a narrow window, the plan timeline is a list of cards rather than the chart. Each card carries the dates, how far the row has slipped against the baseline, how far it has got, and whether it is on the critical path. The dependency arrows are the one thing the cards cannot show, and the list says so: open the plan on a wider screen to read the network.
44. 44To 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.
45. 45To adopt a project's tasks into the plan, give a plan row a task, or import a project's risks into the RAID register, link the project first. Open the engagement, find Linked project on the Overview tab, choose the project and press Link project. Use Change the project or Remove the link there later.
46. 46To let people draft status reports, minutes, register items, deliverable checks and health explanations, an owner or an administrator opens Settings, Client Delivery, turns on Allow AI drafting in Client Delivery and presses Save AI drafting setting. Drafts are then requested from the Assistant tab of an engagement.

How does a client actually get into the client portal?

Somebody at the firm issues them an invitation from the People tab of the engagement, and the client opens the link it contains and signs in with the address it was sent to. If they have no account they create one with that address, and the invitation carries on by itself. The portal then opens at its own address and shows only that one engagement. Client portal, in the sidebar under Client Delivery, sets out the whole process including what the client will see.

How does a client get back to the portal later?

They sign in on the usual Atlas sign-in page with the address they were invited at. Client portals, in the account menu at the top right, then opens the list of engagements they hold a seat on, and it appears only for people who hold one. The address /portal goes to the same list directly. A person whose only access is a client portal is given a personal space of their own the first time they sign in, so they have somewhere that is theirs, and the account menu takes them to the portal from there.

Can a portal client see the rest of our workspace?

No. Accepting an invitation gives the client a guest seat, which counts against your plan and is listed with your team as a guest, but it is not a place in your workspace. Your workspace is not offered in their list of workspaces, they cannot switch into it, and every request they make outside the portal and their own profile is refused. To bring the same person into the workspace on purpose, invite them from Team settings or give them a role there: they then become a member with the role you chose, charged as a seat like anybody else.

A client says their invitation link does not work. What happened?

There are two common reasons and they read differently on screen. If the page asks them to sign in, the invitation is fine and they simply opened it while signed out; signing in with the invited address continues it. If the page says the invitation is not valid, the link has expired (after fourteen days unless the firm set another period), has been withdrawn, or has already been used, and the answer is a fresh invitation. Atlas deliberately does not say which of those it is, because a message that told them apart would confirm to anybody holding a guessed link that an engagement exists behind it.

Does inviting a client cost anything?

A client who accepts holds a guest seat on your plan for as long as their access lasts, and withdrawing their access releases it. Issuing an invitation to somebody who already holds a live seat, or who already has an invitation waiting, does not ask for a second one.

What does a legal hold on a working paper file do?

It puts the file beyond destruction while a matter is live. It does not lock the file or restrict who may read it, and the destruction control is not offered at all while a hold is in place. Both placing and releasing a hold require a reason, because a hold with no reason cannot be released by somebody who was not there when it was placed.

The seal check says the file does not match. What does that mean?

The papers in the file are no longer what was sealed. That is a finding to investigate rather than an error to retry, so Atlas reports it and never repairs it for you. A failure to run the check at all is shown differently, because it says nothing about whether the file is intact.

How do I control which parts of a status report the client sees?

Each section of the report carries its own audience. A section marked for the client is in the copy they read; one kept internal is not. The audience is shown on the section itself rather than behind an edit form, so you can see who reads each part before you issue it.

What happens if I send a status report twice?

Anybody who already received it is skipped rather than sent it again, and the message afterwards says how many were sent and how many were skipped. That is what makes it safe to add one more recipient and send again.

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. 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?

Each surface has its own address under the portal navigation: an overview that summarises the rest, analytics, 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 risks, issues and decisions the firm chose to show, 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 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. These surfaces have no portal endpoint at all: the acceptance file and its screening checks, the commercials, the stakeholder map, the working papers, the hypothesis tree and interview programme, the lessons learned, the workspace directory, and meeting transcripts. The RAID register is served only as the risks, issues and decisions the firm marked visible to the client and not confidential. 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 that can be used once and is valid for fourteen days unless the firm sets another period. 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 are on the People tab of the engagement, where Portal invitations issues and revokes invitations and Access grants adds and revokes grants, and each is also available through the API. 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.

Why is Adopt from the board greyed out on the plan?

The engagement has no linked project, so there is no board to adopt from. Open the Overview tab and link a project under Linked project. The adopt control, the task shortcut on each plan row and the RAID import from the project then become available. The same note appears on those screens, with a link to the Overview.

Why can I not ask for a draft on the Assistant tab?

Either AI drafting is off for the workspace or no model provider is available, and the Assistant tab says which. An owner or an administrator turns drafting on in Settings, Client Delivery, and adds a provider in the AI provider settings. Drafts are proposals, and nothing reaches a register until a person accepts named parts of it.