Unilaterally

Podcast 2 — In conversation

Speaker A: The adverb unilaterally is one of those words that does significant work in political and legal communication by embedding a procedural criticism directly into the description of an action. When a journalist writes that a government acted unilaterally, they are not just describing what happened — they are signalling that the expected or appropriate action would have involved cooperation with other parties that was not obtained. The word shifts the reader's evaluation of the action before any explicit criticism is made. This is why the word appears so frequently in diplomatic communiqués and legal filings — it encodes the procedural objection in the description of the event itself.

Speaker B: In employment law, acting unilaterally to change employment terms is a specific and consequential legal concept. Employment contracts are bilateral — both the employer and employee agree to their terms. When an employer unilaterally changes a contractual term — reducing pay, changing hours, altering job responsibilities — without the employee's agreement, the employer has potentially breached the employment contract. The employee may accept the change, raise a grievance, or in the most serious cases resign and claim constructive dismissal. The word unilaterally in this context is not merely descriptive — it is a legal characterisation that triggers specific rights and remedies.

Speaker A: Unilaterally versus independently — what is the distinction?

Speaker B: Independent action focuses on the actor's autonomy and self-determination — acting on one's own judgment and initiative. Unilateral action focuses on the relationship to other parties — acting in a shared space without their involvement. A solo climber who independently summits a mountain without a team is acting independently but the word unilaterally does not apply because there are no other parties whose involvement was expected. A business partner who independently decides to sell the company's assets without consulting their co-partner acts both independently and unilaterally — because the co-partner had an expected role in that decision. Unilaterally is specifically relational, not merely independent.

Speaker A: What is a common mistake about unilaterally?

Speaker B: Using it to describe any decision made by a leader or authority without realising that unilaterally requires an expectation of joint participation that has been bypassed. A CEO making a business decision is not necessarily acting unilaterally — they may have full authority to make that decision without any joint process. Unilaterally applies when the expectation — whether legal, contractual, diplomatic, or relational — is that the decision should involve other parties, and it does not. The word's critical charge depends on that expectation being present. Without it, you are simply describing a decision, not a procedural breach.

Speaker A: Any close synonyms?

Speaker B: Single-handedly implies doing something alone, often with a flavour of impressive individual effort rather than procedural exclusion of others. On one's own is the plain-English equivalent — she decided on her own. Without consultation describes the procedural failing specifically — acting without seeking the views of those who should have been involved. Independently, as discussed, focuses on autonomy rather than the relational dimension. Of one's own accord implies voluntary action without external prompt, which is close but lacks the multi-party context. Unilaterally is the most precise adverb for the specific concept of acting alone in a context where joint action was the expected or required norm.

Podcast 3 — Prompt engineering

Speaker B: Welcome to the workshop. Today we prompt AI using the word unilaterally — building the one-sided action logging systems, single-party decision audit tools, unilateral configuration change detectors, single-actor workflow prevention systems, and coordination enforcement tools that ensure actions in shared systems are not taken without the required participation of all affected parties.

Speaker A: So unilaterally tells the AI to build the coordination enforcement systems — the workflow engines that prevent a single user from unilaterally completing a sensitive multi-party process, the audit tools that surface all actions taken by a single actor without the required co-authorisation, and the change monitors that detect when a service unilaterally modifies shared resources?

Speaker B: Exactly. It signals single-actor action prevention, co-authorisation enforcement, and unilateral change detection. Let me start with a four-eyes enforcement workflow.

Build a four-eyes principle enforcement system: require that any action above a configurable sensitivity level must be initiated by one authorised user and confirmed by a second different authorised user before it is executed. Prevent the initiating user from acting as their own confirmer. Support defining sensitivity levels per action type — high sensitivity for financial transfers and permission changes, medium for data exports, low for standard operations. Log every four-eyes action with the initiator, the confirmer, the action, the timestamp, and whether the confirmation was granted or rejected.

Speaker B: Four-eyes system requires initiation-plus-different-confirmer for sensitive actions, prevents self-confirmation, supports per-action-type sensitivity levels, and logs every four-eyes action with initiator-confirmer-action-timestamp-outcome — the AI builds the sensitivity classifier, the confirmation gate, the self-confirm preventer, the notification sender, and the action log.

Speaker A: Preventing the initiating user from acting as their own confirmer — the self-confirmation prevention — is the core security property of the four-eyes principle: the entire purpose of requiring two authorisations is to ensure that no single actor can unilaterally execute a sensitive action; a system that allows self-confirmation is four-eyes in form but not in substance, providing the appearance of oversight without the reality.

Speaker B: Self-confirmation prevention as the four-eyes-in-substance-not-just-form security property. Now the co-authorisation schema.

Design a co-authorisation and multi-party action schema: an action_types table recording each defined action type with an ID, name, description, required authorisation level as single, dual, or quorum, the minimum approver count for quorum, and the approver role required. A pending_actions table recording each initiated action waiting for co-authorisation with an ID, action type ID, initiating user ID, action payload as JSON, initiated timestamp, expiry timestamp, and current status as pending, approved, rejected, or expired. A co_authorisations table recording each co-authorisation provided with the pending action ID, the authorising user ID, the decision, any comment, and the authorisation timestamp. A action_completion_log recording each completed action with the action type, the initiator, all co-authorisers, the final status, and the completion timestamp.

Speaker B: Co-authorisation schema stores action types with required authorisation levels, pending actions with payload and expiry, co-authorisation records per action, and a completion log with full participant records — the AI builds the four-table schema.

Speaker A: The expiry timestamp on pending actions — automatically expiring actions that have not received co-authorisation within a time limit — is the stale-authorisation security mechanism: a pending high-sensitivity action that sits unconfirmed for days represents a window during which the action context may have changed; automatic expiry ensures that authorisations are time-limited and the initiator must re-initiate with fresh context if the action is still needed.

Speaker B: Pending action expiry as the stale-context re-initiation-required security mechanism. Next, the unilateral action audit interface.

Design a security audit interface for a system administrator: show a timeline of all sensitive actions taken in the past thirty days, colour-coded by authorisation type — green for properly co-authorised, amber for single-authorisation within allowed scope, and red for actions that bypassed required co-authorisation. Allow filtering by action type, actor, and date range. Display a summary panel showing the total count of each colour category. Allow clicking any action to see its full detail — who initiated, who confirmed or failed to confirm, and what the action was. Export the full audit log as CSV for compliance reporting.

Speaker B: Security audit interface shows a thirty-day action timeline colour-coded by authorisation compliance, filtering by type-actor-date, a summary count panel per category, click-to-detail with full participant information, and CSV export for compliance — the AI builds the timeline, the colour coding, the filters, the summary panel, the detail view, and the exporter.

Speaker A: Colour-coding actions by authorisation compliance — green for properly co-authorised, amber for single-authorisation within scope, and red for bypassed required co-authorisation — transforms the audit log from a list of events into a compliance status map: an auditor reviewing the log can instantly identify the red entries that require investigation without reading every line, and the ratio of green to amber to red gives an immediate health-of-compliance picture.

Speaker B: Authorisation-compliance colour coding as the list-of-events to compliance-status-map audit efficiency transformation. On to single-actor risk detection.

Create a privileged account behaviour monitoring system: track all actions taken by privileged accounts — system administrators, database administrators, and security officers. Detect sequences of actions that suggest a single actor is unilaterally accumulating capabilities — granting themselves new permissions, accessing sensitive data, and exporting it within a short time window. Alert the security team when such a sequence is detected, even if each individual action was authorised. Generate a weekly privileged account behaviour report showing the actions taken by each privileged account.

Speaker B: Privileged account monitor tracks all admin actions, detects permission-accumulation-then-data-export sequences as single-actor risk, alerts even when individual actions are authorised, and generates weekly per-account behaviour reports — the AI builds the action tracker, the sequence detector, the context-aware alert, and the weekly reporter.

Speaker A: Alerting on sequences of individually-authorised actions that together suggest a risk — rather than alerting only on actions that are individually unauthorised — is the insider threat detection pattern: a compromised or malicious privileged account will typically take individually allowed actions in a sequence that reveals the intent; detecting only unauthorised actions misses the threat that operates entirely within its permissions but in a pattern that should not occur.

Speaker B: Sequence-of-authorised-actions risk detection as the individually-allowed but combined-intent insider threat pattern recognition mechanism. Now something whole.

Build a financial transaction authorisation and fraud prevention platform: require dual authorisation for payments above a configurable threshold. Apply unilateral-action detection to flag patterns where a single user is both creating and approving transactions within the same period. Support configurable approval chains by transaction type and amount. Integrate with a real-time fraud scoring engine to flag high-risk transactions for additional review. Generate daily transaction authorisation reports for the finance team and monthly compliance reports for auditors.

Speaker B: Financial authorisation platform requires dual sign-off above threshold, detects single-user create-and-approve patterns, supports configurable approval chains by type and amount, integrates with fraud scoring for additional review, and generates daily and monthly compliance reports — the AI builds the full financial transaction authorisation and fraud prevention platform.

Speaker A: Detecting single-user create-and-approve patterns — flagging when the same person creates a payment and approves it within the same period — is the segregation-of-duties fraud prevention mechanism: the fundamental control against payment fraud is ensuring that the person who creates a payment cannot also be the person who authorises it; detecting when this separation collapses, even in a system that formally requires two approvers, surfaces the control failure.

Speaker B: Create-and-approve single-user pattern detection as the segregation-of-duties collapse surface mechanism. Last one — distributed decision consensus API.

Write a distributed multi-party decision coordination API: allow multiple parties to a joint decision to record their position — agree, disagree, or abstain — on a proposed action. Prevent any single party from marking a joint decision as finalised unilaterally. Enforce the decision rule — unanimous, simple majority, or qualified majority — configured per decision type. Return the current decision status and the outcome once the rule is satisfied. Expire the decision proposal after a configurable period if the rule has not been satisfied. Log all decisions with the full record of each party's position.

Speaker B: Multi-party decision API records per-party positions, prevents unilateral finalisation, enforces configured decision rules per type, returns current status and outcome on rule satisfaction, expires unresolved proposals, and logs full position records — the AI builds the position recorder, the unilateral-finalisation preventer, the rule evaluator, the status returner, the expiry handler, and the decision log.

Speaker A: Preventing unilateral finalisation — ensuring no single party can mark a joint decision as finalised even if they are the only responder — is the governance integrity property that makes the multi-party system meaningful: a decision API that allows the initiating party to finalise after a timeout without responses has created a system where apparent consensus masks the reality of unilateral action.

Speaker B: That is the goal — one procedural word, better-managed co-authorisation and joint-action enforcement systems. Keep it in your kit.