Delivery Architecture

Curriculum

Durations include the exercise and are meant honestly rather than optimistically — a lesson estimated at thirty minutes takes about thirty minutes. A lesson that would run past twenty-five minutes has been split into two.

1. Module 1 · 110 min · 4 lessons

   Designing the deployment

   Before anything is configured, a document: what is being deployed, in what order, bound to which region, and — the section that distinguishes a good design — what it will not do. Every lesson here produces a section of that document.

   1. Concept30 min

      Sizing, and where the architecture stops scaling

      This is not built for petabyte ingest, and a relational search is adequate at the volumes it targets — which is part of why the price is what it is. Knowing where that ceases to be true is an architect's job, and quoting a customer past it is the most expensive mistake available here.

      After this lesson you can

      • Estimate log volume for a described organisation and compare it against the allowance.
      • Identify the point at which the search architecture stops being adequate and state what you would do then.
      • Size endpoints and non-human identities separately from human identities, and explain to the customer why they are priced separately.
      • Recognise the organisation shape that should not buy this, and say so.
   2. Concept25 min

      Home-region binding: what it is, and what it is not

      An organisation is bound to a home region and a request from another region is refused rather than served. That is an architectural mechanism, and it is a narrower claim than data residency. The gap between the two is where careful buyers concentrate their questions.

      After this lesson you can

      • Explain the binding mechanism precisely, distinguishing it from a residency guarantee.
      • State the AI inference position accurately, including that it is reported as unverified because the provider offers no contractual guarantee.
      • Draft the residency section of a design document that a data-protection officer would accept.
      • Recognise when a customer's requirement genuinely cannot be met, and say so early.
   3. Concept25 min

      Sequencing the modules

      Identity first, always, and not for a philosophical reason: without it the other three modules produce findings about accounts nobody can act on. Then logs, then endpoints, then privileged access — and the reason privileged access is last is that it is the only module that can lock a customer out of their own business.

      After this lesson you can

      • Produce a sequenced rollout plan with a gate between each stage and a named exit criterion.
      • Justify the ordering against a customer who wants endpoints first because that is what they were breached through.
      • Define what 'done' means for each stage, in terms somebody could verify.
      • Identify the two stages where the first fortnight of baseline formation must be built into the timeline.
   4. Hands-on lab30 min

      Writing the section that says what it will not do

      The section most designs omit and the one that makes a design defensible. Two of the published limits are commercial rather than technical and both are the kind a customer discovers at the worst moment; a design that names them up front is one you can stand behind in two years.

      After this lesson you can

      • Write a limits section covering detection, coverage, on-call, licence dependencies, platform gaps and the two unavailable commercial add-ons.
      • Phrase each limit so it is informative rather than defensive.
      • Get the limits section read and acknowledged by the customer's decision maker specifically, not by their IT contact.
      • Distinguish a limit that will change from one that is structural, and mark them differently.

      Exercise

      Write the limits section for a real or realistic customer

      You need

      • A described organisation — a real prospect or a detailed hypothetical

      Steps

      1. List every published hard limit and mark those that apply to this customer.
      2. Add the customer-specific gaps: unsupported platforms, licence-dependent checks, anything they run that the sensor cannot see.
      3. Add the two commercial gaps — EU-resident inference, human escalation — and state plainly that both are priced and unavailable.
      4. Mark each limit as structural or expected-to-change, and date the ones you expect to change.
      5. Rewrite every sentence that reads as an excuse so it reads as information.
      6. Have somebody who has never seen the design read it and tell you what they now think the product will not do.

      How you know it worked

      A reader who had not seen the design correctly described the product's limits back to you. That is the test, not the document's length.

2. Module 2 · 105 min · 4 lessons

   The privileged-access rollout

   The only module that can lock a customer out of their own systems, which is why it is last in every sequence and has its own course module. The distinguishing skill is knowing which credentials never go under automation and being immovable about it.

   1. Concept25 min

      The session proxy, and why the operator never holds the password

      The operator authenticates to the gateway; the gateway retrieves the credential and opens the upstream connection. The raw credential never reaches the person doing the work, so it cannot be reused, shared or pasted into a chat window. That single property is most of the value of the module.

      After this lesson you can

      • Explain the injection model to a systems administrator who is about to lose direct access, in a way that does not read as distrust.
      • State what is recorded, how it is encrypted, and what a review can search.
      • Identify the failure mode that most concerns administrators — the gateway being unavailable — and design the break-glass path for it.
   2. Concept20 min

      Protocol coverage, stated exactly

      What is proxied, at what fidelity, and what is not. The SMB and mid-market estates you will be designing for are Windows-heavy, which makes this the lesson where a design most often turns out to be undeliverable.

      After this lesson you can

      • State exactly what session fidelity is available per protocol, including that there is no pixel replay for Windows sessions.
      • Determine, for a described estate, what proportion of privileged access the module can actually mediate.
      • Decide whether the answer changes the recommendation, and be willing to say it does.
      • Identify one further gap that will bite an IPv6-only environment.
   3. Hands-on lab35 min

      Designing rotation, and the credentials that are never automated

      Several rotation engines exist and cover most of what a mid-market estate holds. This lesson is about which targets to place under rotation, in what order, and the short list that is never automated at any tier for any reason.

      After this lesson you can

      • Produce a rotation plan by target type, with a staging order and a verification step per type.
      • State the never-automate list and defend it against a customer who wants everything rotated.
      • Design the verification that proves a rotation applied, in both directions.
      • Identify the target types verified against real systems versus those tested against mocks only, and stage accordingly.

      Exercise

      Break a rotation on purpose, in a lab you own

      You need

      • A disposable Linux host and a disposable database
      • Permission to lock yourself out of both

      Steps

      1. Configure rotation for both targets and run it.
      2. Verify each in both directions: the new secret authenticates, the old one is rejected.
      3. Now deliberately misconfigure one so that rotation changes the target and the vault does not receive the new secret. Observe what the dashboard says.
      4. Recover the target. Note how you did it and how long it took.
      5. Write the pre-flight checklist you would run before enabling rotation on a customer's production system.
      6. Write the never-automate list and the sentence you will use when a customer pushes back.

      How you know it worked

      You locked yourself out of a target, recovered it, and produced a pre-flight checklist and a never-automate list. Doing this in a lab is much cheaper than the alternative.
   4. Concept25 min

      Just-in-time elevation, approvals and the standing-rights problem

      Standing administrator rights are the thing being removed. Elevation is requested, approved, time-boxed and expires without anybody remembering to revoke it. The design question is who approves, and what happens at two in the morning when that person is asleep.

      After this lesson you can

      • Design an approval topology with no single point of human failure and no self-approval.
      • Set default session durations and justify them — a long default with approval off is a control that is not a control.
      • Design the emergency path, and state how it is audited differently.
      • Explain why granting, extending or elevating privileged access is never automated and is not exposed to the model at all.

3. Module 3 · 115 min · 4 lessons

   The autonomy envelope as a governance artefact

   The module that makes the difference between an architect and a senior administrator. An autonomy configuration is a set of switches; an autonomy envelope is a document a risk committee has approved, with a justification per action class and a review date.

   1. Concept25 min

      The ladder, and the three transitions that carry the risk

      Six rungs from reporting to acting-and-adapting. Only three transitions matter: grounding gates the move to recommending, a server-enforced envelope gates the move to acting, and the top rung deliberately does not exist because rule-writing autonomy without versioning and rollback quietly degrades coverage.

      After this lesson you can

      • Place a described capability on the ladder and justify the placement.
      • Explain each of the three gates and the failure it prevents.
      • Explain why the model's proposal is not an input to its own permission, and why that is the design's load-bearing property.
      • Answer the question 'why not full automation?' with an argument rather than a policy.
   2. Hands-on lab35 min

      Justifying autonomy per action class

      A blanket consent is a consent nobody read, which is why opt-in is per action class with the risk stated at the point of consent. This lesson produces the document: each class, the risk accepted, the reversal path, the blast radius, and who signed.

      After this lesson you can

      • Produce a per-action-class justification document for a described organisation.
      • Order the action classes by how readily most organisations accept them, and explain the ordering principle.
      • Articulate the design principle that step-up authentication is autonomous-safe and account suspension is not.
      • Set a review date and define what would cause you to revoke a class early.

      Exercise

      The envelope document

      You need

      • A described organisation with a real risk appetite

      Steps

      1. List every action class available for autonomous execution.
      2. For each, write the blast radius, the reversal path, and who the affected person would be.
      3. Order them by acceptability and mark the line above which this organisation will not go.
      4. For the classes above the line, write the specific condition that would change your recommendation.
      5. Add a review date and the trigger conditions for an early review.
      6. Take it to your hostile risk committee and note every question you could not answer.

      How you know it worked

      A signed-off envelope document, and a written list of the committee's questions you could not answer — that list is the real output of this exercise.
   3. Judgement35 min

      Defending the envelope to a hostile committee

      Ninety minutes with somebody playing a risk committee that has read one alarming article about AI agents. The objections are predictable and the answers have to be short. This is the single highest-value hour in the course.

      After this lesson you can

      • Answer 'what happens when it is wrong?' with a specific mechanism rather than a reassurance.
      • Answer 'who is accountable?' without deflecting to the vendor.
      • Answer 'can it be talked into something?' with the permission-resolution argument.
      • Concede a real limitation mid-meeting without losing the room.
   4. Concept20 min

      Reviewing an envelope after it has been live for a quarter

      The envelope you set before any data existed was a guess. After a quarter you have agreement rates, escalation rates and a set of decisions somebody disagreed with. This lesson is the review that turns the guess into a decision.

      After this lesson you can

      • Define the three measurements you need before the first review, and set them up on day one.
      • Decide, from real data, whether a class should move up or down.
      • Recognise the pattern where high agreement reflects nobody reading the queue rather than good decisions.

4. Module 4 · 115 min · 4 lessons

   Procurement, and migrating off an incumbent

   Two adversarial situations. A questionnaire designed to catch you overstating, and a migration where the risk is a coverage gap in the middle that nobody notices until it is over.

   1. Judgement35 min

      Surviving a two-hundred-question security questionnaire

      Twenty real questions, five of which have an honest answer that is worse than the answer the customer wants. The competence being taught is the wording that is both accurate and survivable, and knowing which five to escalate rather than answer.

      After this lesson you can

      • Answer residency, sub-processor, encryption and AI-governance questions accurately.
      • Identify the questions requiring a contractual commitment you cannot make, and route them.
      • Recognise the question designed to catch you overstating, and answer it in a way that gains credibility.
      • Explain why an answer you cannot evidence is a liability rather than a sale — including for you personally.
   2. Concept20 min

      The trust surface, and pointing at it rather than paraphrasing it

      There is a published trust position, a published list of claims we refuse to make, and an AI Act system card. Pointing a buyer at a published position is stronger than restating it, and it is safer for you: a paraphrase you got slightly wrong is a commitment you did not intend to make.

      After this lesson you can

      • Locate the published position for four common buyer concerns.
      • Use a published refusal as a credibility argument rather than an apology.
      • Explain why a vendor publishing the sentences it will not write is making a claim a competitor cannot copy cheaply.
   3. Hands-on lab35 min

      Migrating off an incumbent without a gap in the middle

      The dangerous part of a migration is the overlap. Dual-send, staged cutover, and an honest coverage comparison — which will show the incumbent doing something better, and a design that pretends otherwise gets found out in the first month.

      After this lesson you can

      • Produce a migration plan with a dual-send period and a defined cutover criterion.
      • Compare detection coverage against the incumbent honestly, including where they are ahead.
      • Identify what will break during the overlap, and tell the customer before it does.
      • Define the rollback: what happens if cutover fails at three in the afternoon.

      Exercise

      Plan a migration from a named incumbent

      You need

      • A real or realistic incumbent stack
      • The incumbent's own published coverage claims

      Steps

      1. List what the incumbent covers, from their documentation rather than from memory.
      2. Map it against our coverage. Mark every cell where they are ahead.
      3. Design the dual-send period, with a length and a comparison method.
      4. Define the cutover criterion as something measurable, not as a date.
      5. Write the rollback plan, including who authorises it.
      6. Write the paragraph you will give the customer about where the incumbent was better. This is the paragraph that earns their trust for the next two years.

      How you know it worked

      A plan with a measurable cutover criterion, a rollback with a named authoriser, and a written honest concession about the incumbent's strengths.

   4. Judgement25 min

      Recognising when we are the wrong choice

      Five prospects. In two of them the right recommendation is a different product or a different approach. An architect who cannot produce that recommendation is a salesperson, and the practices that last are the ones that occasionally say no.

      After this lesson you can

      • Identify the disqualifying conditions from the published limits and apply them to a described prospect.
      • Produce a recommendation against the sale, with reasons, and name what they should buy instead.
      • Recognise the shape where the customer's real requirement is a human on call, and say where to buy one.
      • Explain the commercial argument for declining a sale you could have made.