Lesson 3: How Sector and Context Shape Platform Choice

By the end of this lesson, you will be able to:

• Explain why the same use case can call for different platforms in different organisational contexts (K8, K25)
• Identify the defining constraint that most shapes platform selection in a given sector (K8, K2)
• Recognise the reasoning pattern that connects a constraint to a platform characteristic, and apply it beyond the sectors covered here (K8, K25)
• Begin locating your own project's defining constraint ahead of the five-dimension assessment (K25)
• Curate your Evidence Companion's knowledge base from your real project materials, applying a tier-aware "safe to upload / never upload" rule (K8, K2, B6)
• Put your Evidence Companion to work generating a first-draft constraint analysis from the project context it now holds, and critically evaluate its output — especially compliance claims — instead of accepting it (K9, S8)

From capability to context

The last two lessons taught you to read a platform: what it can do, where it stops, its risks, its cost, and who it suits. That is necessary knowledge. It is not sufficient on its own to make a selection.

The question that actually decides a project is sharper than "what can this platform do?". It is "what should I use for this problem, in this organisation, given these constraints?". Two organisations with an identical use case can correctly arrive at different platforms, because their contexts differ. A marketing agency automating social media drafting and a hospital automating patient correspondence might both want an AI writing step, but the hospital's data obligations rule out platforms the agency would happily use.

This lesson develops the habit of reading context before reaching for a platform. The vehicle is a set of common sectors, grouped by the constraint that tends to dominate platform choice in each. The sectors are illustrations, not a list to memorise. What matters is the reasoning pattern they share: identify the defining constraint, and it cascades into which platform characteristics become non-negotiable.

Constraint patterns across common sectors

The sectors below are grouped by the constraint that tends to dominate platform selection, so you can see several different sectors resolving to the same underlying reasoning. Read this as a reference that shows the pattern, not as content to commit to memory. The example platforms in the final column are illustrative, not prescriptions — they show what a fit looks like, not what you must choose.

The column that does the work is the third one — the defining constraint. Once you have named it correctly, the non-negotiables in the final column follow from it. The skill is identifying the constraint, because that is where the real judgement lives — not in reading an answer off the table.

Did you know?

The same parent company can house teams with opposite platform needs. A bank's marketing team and its client-services team might sit two floors apart and correctly choose entirely different automation platforms, because their data obligations differ even though their employer does not. Context is local, not corporate.

Curate what your Evidence Companion is allowed to know

Everything in this lesson is about to become concrete. For your Companion to help you reason about your project, it needs your project's own material — the project definition and current-state process from Module 1, the systems and data types the project touches, and your organisation's relevant templates and competency wording. Loading that context is what lets the Companion give useful, project-specific answers instead of generic ones. It is also exactly where sector and context stop being theory: what you may and may not upload is set by your project's defining constraint and by the data tier you chose back in Unit 1.

The rule is the same tier-aware discipline you met with transcription, applied to files. On a consumer chat tier, assume anything you upload could be used to improve the model, so almost nothing organisational belongs there. On a sanctioned business or enterprise tier — a Claude business tier, or Microsoft 365 Copilot with Enterprise Data Protection — the data stays inside a governed boundary and is not used to train the foundation models, so more is permissible, but your organisation's policy and other people's data still set the limit. Curating is deciding, file by file, which side of that line each item sits on.

✅ Safe to upload / ❌ never upload — a starting checklist to adapt to your own constraint

• ✅ Generally safe: your own drafts and notes about your own work; public or already-published material; blank templates and competency wording; anonymised or synthetic examples.
• ⚠️ Only on a sanctioned tier, and only if policy allows: internal process documents, non-public organisational templates, and your own evidence containing limited internal references.
• ❌ Never upload (unless informed): customer or client PERSONAL data; special-category data (health, and similar); anything covered by confidentiality or contract you are not authorised to share; third parties' personal data gathered without a basis; credentials and secrets.

When an item is borderline, treat it as the more sensitive category until someone who owns the policy tells you otherwise.

"But doesn't connecting my email do the same thing?" A fair question, and worth settling before it trips you up. Elsewhere on the programme you connect an email tool — a Gmail or Outlook MCP — that lets your assistant read your inbox at runtime. That can look like it contradicts the "never upload client personal data" rule. It does not, because the two acts are different in kind:

• Connecting a tool that reads email at runtime (a governed MCP on a sanctioned tier) is transient, policy-governed processing. The assistant reads a message to act on it in the moment; the data is not copied into the assistant's permanent memory, and access is controlled by your organisation's licence and admin policy. The tool sees data as needed and then it is gone.
• Uploading a spreadsheet of client contacts as knowledge is deliberately making third-party personal data part of the assistant's persistent memory. That data now sits in the knowledge base indefinitely, available for every future answer, whether or not any single task needs it.

The line, then, is not "does the assistant ever touch personal data?" — governed tools sometimes must. It is "am I depositing other people's personal data into the Companion as standing knowledge?" Runtime access through a sanctioned, policy-governed connector can be legitimate; turning a file of real client details into permanent Companion knowledge is the thing the "never upload" rule forbids.

[CURATE IT — 15 minutes] Decide which of your real project materials your Companion should and should not hold, and why.

Generate and pressure-test your analysis with your Companion

Your Companion now holds your curated project context — the definition, the current-state process, the systems and data types it touches. That is exactly the raw material a constraint analysis needs. So put the Companion to work: ask it to produce a first-draft constraint analysis for your own project, then interrogate what it gives you.

The point is not to be handed an answer — and the way to avoid that is to commit your own view first. Before you open the Companion, write one sentence naming what you think your project's defining constraint is, and whether it is a hard limit or a soft preference. That sentence is what turns the next step into a check rather than a copy: you compare the Companion's draft against your own reasoning instead of adopting it in place of reasoning. If you skip it and read the Companion's answer first, you have anchored yourself to its view and lost the thing being assessed — your judgement. The output is a draft to challenge, not a verdict to accept.

Because the Companion already has your project context and its own system prompt, you do not paste a fresh "you are an assistant that…" persona, and you do not re-describe your role, sector, and systems. You give it the task and let it reason over what it already knows. Fill a [bracket] only where the Companion does not yet hold that detail.

How to run it:

1. First, and without the Companion, write your own answer: in one sentence, name the defining constraint you think your project has, and whether it is a hard limit or a soft preference. Do not skip this — it is what lets you judge the Companion rather than defer to it. (Capture it in the first field of the activity below.)
2. Open your Evidence Companion — the Claude Cowork or Copilot agent you built, now loaded with the project materials you just curated.
3. Paste the request below. Complete any [bracket] the Companion could not already know from its knowledge base.
4. Read the response against the constraint you wrote in step 1: do they agree? Where they differ, work out which is right and why — and be ready to overrule the Companion, not just to correct your own note.
5. Treat every compliance claim as unverified until you have checked it (see the caution below).

Using the project context you already hold, help me choose an automation
platform for this project. Work through the following, showing your reasoning
at each step:

1. Identify the single defining constraint that should most shape my platform
   choice — the one factor that, if ignored, would rule a platform out. Explain
   why it dominates the others.
2. State whether that constraint is a hard limit (legally or contractually rules
   platforms out) or a soft preference (would be nice, but could flex).
3. List the platform characteristics this constraint makes non-negotiable (for
   example: control over data residency, a native connector to a named system,
   built-in human-approval steps).
4. Suggest two or three platform types or named examples that tend to meet those
   characteristics — clearly labelled as starting points for me to evaluate, not
   a final recommendation.
5. Flag anything you are uncertain about, and list what I must verify with my own
   compliance, IT, or data-protection team before relying on your answer.

If anything you need is missing from the project material you hold, ask me for it
rather than guessing. Do not give me a single definitive "use this platform"
answer — surface the constraint and the trade-offs so that I make the decision
myself.

Be most sceptical exactly where your Companion sounds most confident: compliance. Because you built it and pointed it at your own project, its answers can feel more authoritative than a stranger's chatbot — and it will still happily state regulatory "facts" about UK GDPR or NHS data governance that are outdated, oversimplified, or wrong, in a fluent and confident tone. Never let it settle a data-protection question — take any compliance claim to your DPO, IT, or legal team to confirm. Use the output to sharpen your reasoning about the constraint, not to replace it. That habit of identifying the constraint yourself and treating the Companion as a sounding board is the durable skill; the platform names are disposable.

[ANALYSE IT — 10 minutes] Write your own take first, then capture what your Companion proposed and — most importantly — your verdict on it.

Quick Check

⏭️ Up next - Unit 3: You can read a platform, match features to needs, and reason from your context and data constraints. Unit 3 turns all of that into a decision: the five-dimension framework that produces a defensible selection, choosing the right tool, mapping the jagged frontier between vendor claims and reality, and writing the platform recommendation for your Companion.

Unit 2: How the knowledge in this unit maps to the apprenticeship