Words for patterns I kept running into and didn’t have a name for. Added as they come, A to Z.
A#
AI Reliability Engineering#
noun
The engineering discipline of ensuring AI-enabled systems produce outputs that are correct, controlled, safe and dependable in operation, not merely technically available.
It applies SRE principles to agent behaviour, grounding, evaluations, policy controls, tool use, traceability, human escalation and operational SLOs.
It makes AI outcomes measurable, detects degradation, and drives corrective changes across models, prompts, agents, tools and workflows.
The small print: infrastructure health alone does not demonstrate that an AI system is meeting its intended standard.
Ambient Compliance#
noun
Compliance designed into how decisions and systems are built: present in the architecture, the defaults and the everyday workflow, so that being compliant is a property of the work itself, not a gate checked before it ships.
Shifting compliance left usually means moving the review earlier: a design check instead of a pre-launch audit. Ambient compliance goes further and removes the discrete checkpoint altogether. The standard lives in the abstraction layer, the templates, the guardrails people build on, so there is nothing separate left to inspect, because the compliant path is also the easiest path.
It reframes central risk and compliance teams from approvers into advisors: they shape the defaults everyone inherits, rather than sitting at the end of the pipeline signing off on work they had no hand in designing. Trust becomes a design principle, not the byproduct of a review that slows everyone down.
The small print: ambient compliance still needs someone accountable for the defaults being right: invisible is not the same as unattended.
C#
Compliance Theatre#
noun
Compliance activity performed to be seen as compliant rather than to be compliant: screenshots gathered because the auditor prefers screenshots, evidence formatted to the auditor’s taste, a roadmap set by the audit calendar instead of the risk register.
The tell is the ordering. A real control produces evidence as a byproduct of doing the work. Compliance theatre produces the evidence first, then works backward to make the activity match it.
It photographs well. Audits pass, certificates get renewed, and the underlying risk the control was supposed to manage is never actually tested, because the performance and the substance were never the same thing.
The small print: an auditor who signs off on the performance has not verified the risk, only the theatre.
D#
Dancing Around Audit#
noun
The pattern where a GRC or security programme organises its calendar, its evidence and its priorities entirely around the next audit: the audit date sets the roadmap, the auditor’s preferred format sets the evidence, and the findings tracker becomes the primary measure of the programme’s health.
Named for “dancing around handbags,” the British term for a fight that is all posture and no contact: two people squaring up, swinging, making a show of conflict that never actually connects. Dancing around audit looks the same from a distance: findings raised, remediation plans opened, action trackers updated, real motion, real noise, but the programme’s own risk priorities never enter the room. The audit sets the agenda instead of validating one that already existed.
The fix isn’t to ignore the audit. It’s to build the programme around the organisation’s own risk and data model first, and treat the audit as one more consumer of that output, not its author. Translate outward when the audit arrives; don’t design inward from it.
The small print: a programme that only moves when an audit is scheduled was never managing risk, it was managing an auditor.
P#
Privacy Theatre#
noun
Privacy controls that satisfy a policy checklist or a consent banner without changing what actually happens to a person’s data: a cookie banner with a pre-ticked “accept all,” a data map that lists systems nobody has actually inventoried, data localisation rules that keep data inside a border while the access controls around it stay exactly as loose as before.
It is easy to mistake for privacy by design, because the artefacts look similar: policies, banners, registers, approvals. The difference is whether anything downstream would actually break if the underlying data handling changed.
It survives because privacy harm is diffuse and delayed, so the theatre rarely gets caught out before the certificate is renewed.
The small print: a data subject cannot tell the difference between privacy theatre and privacy protection until something goes wrong, and by then it’s their problem, not the programme’s.
S#
Security Theatre#
noun
Security measures whose primary function is to be visible rather than effective: the badge reader on a door somebody props open, a password policy so complex it ends up on a sticky note, the quarterly phishing test that trains people to click faster past deadlines rather than think.
It exists because visible control is easier to fund and easier to defend in a post-incident review than invisible risk reduction. A control that is seen doing something reads as diligence, whether or not it changes the odds of anything happening.
The audience is often internal: leadership, auditors, insurers, not the attacker. A real adversary routes around theatre without ever noticing it was there.
The small print: theatre isn’t free. It still costs budget, goodwill and the attention that could have gone to a control that actually works.
Synthetic Borrowed Competence#
noun
The seductive belief that, because AI can generate plausible outputs in almost any domain, a person can therefore build anything, even without the domain knowledge to frame the problem, recognise missing constraints, validate the result, or sustain it in operation.
AI provides real but temporary capability: it allows someone to borrow patterns, language, code and specialist knowledge they do not personally possess. The risk is mistaking that borrowed capability for complete competence, or a plausible output for a viable product.
It works remarkably well for bounded, low-risk work. But as problems become cross-domain, consequential and long-lived, the missing expertise reappears as escalating prompt and token spend, context decay, weak evaluation, inconsistent agent outputs, rework, technical debt and operational risk.
The small print: someone still needs to know what “anything” is supposed to do, how it fits with everything else, and whether it is actually working as intended.
T#
Technical-Debt Low-Interest Loan#
noun
The reassuring belief that a backpatch, compatibility layer, extended-support arrangement or virtual patch has solved a technology problem, when it has merely made postponing the underlying change cheaper and less painful for now.
It provides real but temporary relief: it can reduce immediate risk, avoid disruptive upgrades and keep a system operating while a more fundamental change is deferred. The risk is mistaking that relief for resolution, or a secure old dependency for a sustainable technical position.
It works well when the delay is deliberate, bounded and accompanied by a credible plan to upgrade, replace, redesign or retire the underlying dependency. It addresses the symptom of fragmented remediation exceptionally well. It does not, by itself, address the essential complexity of dependency ownership: knowing why a component exists, whether it is still needed, who is accountable for its lifecycle, when it must be upgraded, and how the system can safely change.
The small print: these programmes may buy time. They must not be allowed to make “not changing” look like a sustainable engineering strategy.