Pharma AI

MLR-Compliant GenAI Content for Pharma

By Multiplier AI Team · Published October 12, 2026

Every pharmaceutical marketing team has now been asked the same question by someone senior: can we use generative AI to produce our promotional content? The honest answer is more interesting than either of the two answers usually given, and it turns on a distinction that most published guidance skips.

The optimistic answer - yes, AI writes the content and the review process catches problems - misunderstands what the review process actually checks. The cautious answer - no, the regulatory risk is too high - forfeits a genuine and large efficiency gain that responsible companies are already banking.

The accurate answer sits between them and is architectural rather than a matter of degree. Use AI to assemble and personalise pre-approved content, not to generate claims. The reasoning behind that principle is specific and worth understanding, because it is what makes the difference between a defensible programme and an expensive one.
Yes - with a constraint that changes the design. Pharmaceutical companies can and do use generative AI in promotional content, but the safe pattern is assembly rather than free generation: build a library of pre-approved modular claim blocks, each linked to its supporting reference, then use AI to select, sequence and personalise within that approved vocabulary. The reason is precise. AI performs well on editorial and structural checks - grammar, risk phrases, boxed warnings, safety information presence, required links. It does not reliably perform the two checks that carry the most regulatory weight: whether a claim is genuinely supported by its cited reference, and whether fair balance is adequate. Those remain human expert judgement, and any architecture that assumes otherwise is unsafe.

Can pharma use generative AI for promotional content?

Yes, and the more useful question is which part of the process it should touch. Promotional content production has four distinct stages, and AI's suitability differs sharply across them.

Stage	What happens	AI suitability	Why
1. Claim creation	Deciding what may be said about the product, and on what evidence	Do not use AI	This is a regulatory and medical determination grounded in the label and the evidence base. A generated claim is an unapproved claim regardless of how well it reads
2. Module authoring	Writing the approved claim into usable content blocks with linked references	Assisted, heavily reviewed	AI can draft variants of an approved claim. Every variant goes through full MLR as a new module. The gain is drafting speed, not review avoidance
3. Assembly and personalisation	Selecting, sequencing and adapting approved modules for a channel, audience or individual doctor	Strong fit - this is where the value is	The claims are already approved. AI is choosing among approved options and adapting non-claim connective text. Risk is bounded by the library
4. Pre-submission checking	Scanning assembled content for compliance failures before formal review	Strong fit, with limits	Structural and editorial checks automate well. Substantive claim verification does not

Almost every failed GenAI content pilot we have seen attacked stage one or two and called it stage three. The team asked a model to write promotional copy, the output was fluent and plausible, and the MLR queue filled with material that had to be reviewed from first principles - which is slower than the process it replaced, not faster, because a human reviewer reading generated text cannot assume anything about its provenance.

The sentence to take into the next steering meeting

AI does not make content compliant. It makes approved content faster to deploy. Everything that follows in this article is an elaboration of that distinction and a programme designed around the first reading will consume review capacity rather than release it.

What AI checks well — and the two things it does not

This is the honest core of the article and the part that determines your architecture. It is worth being specific rather than general, because the boundary is not where most teams assume.

Automates reliably

Veeva's Quick Check Agent, available from late 2025, is a useful reference implementation for what is genuinely automatable, because the vendor has been careful about scope.

Check	What it does	Why it automates well
Editorial	Spelling, grammar, medical terminology consistency	Deterministic and pattern-based
Risk phrase detection	Flags absolute claims and off-label language, with suggested rewording	Pattern recognition over a known vocabulary. "Proven", "safest", "cure" are findable strings
Boxed warning verification	Confirms mandatory warnings are present and correctly formatted	Presence and format are checkable facts
Safety information checks	Validates that safety statements match approved labelling	Comparison against a fixed reference document. Note this is a match check, not a sufficiency judgement
Required links	Privacy, unsubscribe and adverse-event reporting links present and correct	Binary
Accessibility	Alt text, colour contrast, readability against WCAG	Rule-based
Brand and format rules	Trademark usage, channel-specific formatting	Rule-based, and genuinely tedious for humans

Does not automate reliably — and this is the important half

Two checks remain human expert judgement, and they are the two that carry the most regulatory weight. Claims-to-reference verification does the cited study actually support the claim as worded, in that population, at that endpoint requires reading the source and exercising scientific judgement. Fair balance assessment - is the presentation of benefit and risk adequate given the whole piece - is a judgement about proportion and prominence that has no rule to apply. Published analysis of AI in MLR is explicit that these are not fully automated; AI flags suspicious patterns and missing elements, and expert reviewers decide.

The architectural consequence is direct. If the two highest-weight checks cannot be automated, then the way to reduce review burden is to reduce how often those checks are needed - which means approving claims once, at module level, and reusing them, rather than re-verifying a fresh claim in every asset. That is the entire argument for modular content, and it is why the technology answer and the compliance answer converge on the same design.

It also explains a failure pattern worth naming. A team that automates the structural checks and leaves the process otherwise unchanged will see the queue move faster and the review burden stay roughly constant, because the reviewers' time was never mostly spent on spelling. Automating the easy checks does not release the constrained resource.

The modular content architecture

The enabling structure, described concretely enough to specify.

A module is a discrete, independently approved content component a clinical efficacy statement, a safety profile snippet, a product description, a mechanism graphic that can stand alone and be combined with others. A claims library holds each statement in its approved wording with its supporting reference linked. Assembly builds an asset from approved modules rather than from a blank page.

Component	What it holds	Why it matters for AI
Claims library	Each claim in approved wording, with linked supporting documentation and approval status	The constrained vocabulary AI is allowed to select from. Without it, AI has no bounded set and generation is unavoidable
Content modules	Approved blocks, text, and visual each individually reviewed before use	By the time an asset reaches MLR, a large portion is already approved, so review scope narrows to assembly and context
Automatic claims linking	Suggests the correct reference when claim language is inserted	Removes manual lookup, and makes unreferenced claims visible immediately rather than at review
Reference version control	When a reference document is up-versioned, claims supported by it are automatically updated or flagged	A 2025 capability and a significant one. Previously manual, and the failure it prevents a claim silently supported by a superseded reference is exactly the kind an audit finds
Where-used reporting	Identifies every material using a given claim or asset	Essential for withdrawal. When a claim must change, this is how you find everything affected before someone else does
Digital asset management	All assets with metadata product, therapy area, country, type, expiry	Makes assembly possible at all. Expiry metadata prevents the most common quiet failure

The reported gains from modular strategies are substantial and worth quoting to a sceptical stakeholder: approximately 40% increase in content reuse, 30% decrease in approval times, 75% of approvals completed in a single review cycle alongside roughly 19% cost reduction, and about 50% faster speed to market. Separately, organisations have reported a 57% reduction in review cycle time, and Veeva estimates its AI agents can deliver up to a 75% reduction in review cycles.

The trade being made, stated honestly

Modular assembly constrains creative freedom, and pretending otherwise sets teams up to resent it. You are trading the ability to write a bespoke piece from scratch for the ability to ship approved material quickly and repeatedly. For most promotional content rep emails, channel adaptations, market variants, personalised sequences that is an obviously good trade. For a flagship launch asset it may not be, and the risk-tier model in the next section exists so that both can be true at once.

Content risk tiers matching the gate to the risk

The most common governance error is a single approval process for all content. It is calibrated for the riskiest material, so everything moves at that speed, and teams route around it. Tiering solves this.

Tier	Content type	AI role	Required gate
Tier 1 - Highest	New product claims, launch materials, comparative claims, anything referencing a competitor, first use of new clinical data	Drafting support only. No AI assembly without full review	Full MLR: medical, legal, regulatory. No shortcuts, no exceptions
Tier 2 - High	New modules and claim variants entering the library, congress materials, new-channel adaptations of existing claims	Drafting plus structural pre-check	Full MLR at module level, once. Approved modules then flow to tier 3 reuse
Tier 3 - Managed	Rep emails, channel adaptations, personalised sequences assembled entirely from approved modules with no new claims	Assembly and personalisation the main value zone	Automated structural check plus defined-scope human review. Reviewing assembly and context, not re-verifying claims
Tier 4 - Low	Internal training material, non-promotional scientific exchange, logistics and administrative communication	Broad use	Line management review. Note: non-promotional is a determination, not a label - if it contains a product claim it is not tier 4

Two disciplines make tiering work rather than becoming a way to downgrade everything. The tier is determined by the content, not by the deadline - a decision made by medical or regulatory, not by the requester. And any asset containing a claim not already in the approved library is automatically tier 2 or above, regardless of what it looks like. That single rule prevents the drift that otherwise turns tier 3 into a bypass.

How to use GenAI for rep emails without MLR risk

Rep email is the ideal tier 3 use case and the fastest place to see value. The pattern: pre-approve a library of email modules - opening, clinical message variants, safety statement, call to action, sign-off - each individually MLR-approved with its reference linked. AI then selects and sequences modules for the specific doctor and adapts only non-claim connective text. The rep sees a suggested email, can swap modules, cannot edit claim text, and sends. No new claim is created at any point, so the assembled email needs assembly-scope review rather than substantive re-verification.

Element of the email	Who controls it	Can AI change it?
Clinical claim text	MLR, at module level	No. Selection between approved variants only - never editing the wording
Which claim is used	AI, from the approved set for that doctor's specialty and segment	Yes. This is the personalisation
Safety information	MLR, mandatory inclusion rules	No. Presence and content are enforced, not chosen
Sequence and structure	AI, within the template	Yes
Greeting, connective text, sign-off	AI	Yes - this is genuinely non-claim text and where most of the perceived personalisation lives
Subject line	AI, from approved variants	Selection only. Subject lines carry claims more often than teams realise and belong in the library
Call to action	Approved set	Selection only

Three controls turn this from a good idea into a defensible one.

Lock claim text in the interface. Not a policy that reps should not edit claims - a field they cannot edit. Policies degrade under deadline pressure; interfaces do not.
Log the assembly. Which modules, which version of each, which reference, who sent it, when. This log is the audit trail, and it is the thing that makes the whole approach defensible after the fact.
Expire modules automatically. A module whose supporting reference has been superseded should stop being selectable, not merely be flagged. Reference version control makes this possible; without it, withdrawn claims circulate for months.

AI tools that pre-check pharma content for compliance

What exists, what it covers, and what to ask a vendor. The honest framing is that pre-check tools are genuinely useful and are not a compliance function.

Capability	Maturity	What to verify with a vendor
Risk phrase and absolute claim detection	Mature	Is the vocabulary editable by you? Your therapy area and market will have terms the default list does not carry
Safety information and boxed warning presence	Mature	Does it check presence and format, or sufficiency? Presence is automatable; sufficiency is judgement - do not accept the second claim
Required link validation	Mature	Does it cover market-specific requirements, including adverse-event reporting routes?
Claims-to-reference matching	Immature - flags patterns, does not verify	Ask directly whether it verifies that the reference supports the claim, or checks that a reference is attached. These are very different products and are described in similar language
Fair balance assessment	Not automated	Any vendor claiming this is overselling. What is achievable is checking that risk content is present and meets prominence rules
Off-label detection	Partial	Works on obvious cases against the label. Subtle implication is not reliably caught
Reviewer summarisation	Mature and genuinely useful	Synthesising purpose, key claims, risks and check findings into a briefing measurably speeds human review
Accessibility and format	Mature	Low glamour, high volume, real time saving

The single question that separates a real tool from a marketing claim

Ask: "Does your tool verify that the cited reference supports the claim, or does it verify that a reference is attached?" The first is a research-grade problem that nobody has solved reliably. The second is a link check. Both get described as claims checking, and the gap between them is where a compliance programme quietly fails. A vendor who answers this question crisply and admits the limit is a better partner than one who does not understand why it was asked.

The governance model

The half that makes it defensible. Regulators have not issued explicit guidance on AI-aided review, which means they judge the final material rather than the method - and that places the entire burden on documentation.

What you must be able to demonstrate

That a qualified person made the final approval decision. This is the load-bearing requirement. AI-assisted is fine; AI-decided is not. The record must show a named, qualified human approving the material.
That AI outputs were verified rather than accepted. Where an AI suggestion was acted on, particularly on a claim, there should be evidence a human checked it against the source.
What the AI actually did. Suggestions made, accepted, rejected - logged, timestamped and attributable. Platforms that log AI interactions as system actions produce this automatically; bolt-on tools frequently do not.
That the module and its reference were current at the time of use. Version control on both, with the version recorded in the assembly log.
A documented policy on where AI is and is not used. Framed as governance transparency rather than a regulatory mandate, but it is the first document requested when anyone asks how the content was made.

Roles and gates

Role	Owns	Cannot delegate to AI
Medical review	Scientific accuracy, claim-to-evidence fit, fair balance	Both of the two non-automatable checks. This role is the reason the architecture is shaped as it is
Legal review	Regulatory and code compliance, competitive claims, contractual constraints	Judgement on comparative claims and code interpretation
Regulatory review	Label alignment, market-specific requirements	Label interpretation
Content operations	Module library integrity, version control, expiry, where-used	Nothing - but this role determines whether the others can work efficiently. An unmaintained library makes tiering meaningless
Brand and field	Assembly, selection, deployment within approved bounds	Claim creation. The interface should make this impossible rather than prohibited

GET ACTIONABLE AI AND HEALTHCARE INSIGHTS THAT HELP YOU STAY AHEAD IN A FAST-CHANGING PHARMA WORLD

India, UCPMP and the less-formalised MLR problem

An uncomfortable point that the global guidance has no reason to make, and that matters more than the technology choice.

Most published thinking on AI in MLR assumes a mature, formalised review function - dedicated medical, legal and regulatory reviewers, a content platform with version control, an audit trail generated as a by-product of the workflow. In that setting, adding AI is a question of augmenting a working gate.

In much of Indian pharma the gate is less formalised - review may be a brand manager and a medical advisor working in email and shared folders, without a claims library, without version control and without an audit trail generated automatically. Introducing generative AI into that environment increases risk rather than reducing it, because the volume of content rises sharply while the mechanism that would catch a problem does not exist. The sequencing conclusion is uncomfortable and firm: build the claims library and the audit trail before you deploy the generation capability, not after.

What UCPMP governs	Why AI raises the stakes	The control
Promotional claims must be accurate, balanced and substantiated	AI produces fluent text that reads as authoritative regardless of whether the substantiation exists	Claims library with linked references. The claim cannot exist in the system without its evidence
Comparative claims are tightly constrained	Models are strongly inclined toward comparative and superlative framing because that is how marketing copy reads in their training data	Risk phrase detection tuned for Indian code language, plus tier 1 classification for anything comparative
Consistency between what is claimed and what is approved	Volume. A rep sending forty personalised emails a week creates forty artefacts that must each be defensible	Assembly logging. Without it you cannot reconstruct what was actually sent
Accountability for what the field communicates	Personalisation at scale means head office cannot read everything before it goes	Locked claim text in the interface, and expiry that removes withdrawn modules from selection

There is a genuine opportunity inside this, which is worth stating alongside the warning. A company building its content governance now can build it AI-ready from the start - modular, referenced, versioned, logged - rather than retrofitting AI onto a twenty-year-old document-based process, which is what most large Western pharma companies are currently spending heavily to do. Starting later is an advantage if the sequence is right.

A 90-day implementation

Assumes you are starting without a claims library, which is the common Indian and mid-cap position.

Days 1–15: audit what you already say. Collect the last twelve months of promotional material and extract every distinct claim. Most teams find far fewer unique claims than assets - typically a few dozen claims doing the work of several hundred pieces. That ratio is the business case for modular content, and it is more persuasive than any vendor benchmark.
Days 16–35: build the claims library. Each claim in approved wording, linked reference, approval status, expiry, and the markets it is cleared for. This is the entire foundation and it is unglamorous work. Do not start anything else until it exists.
Days 36–50: modularise one brand. Convert one brand's content into approved modules - openings, clinical statements, safety blocks, calls to action. One brand, done properly, teaches more than five done partially.
Days 51–65: define the tiers and write them down. Which content is which tier, who decides, what gate each tier gets. Get medical and legal to sign the tier definitions before any AI touches anything, because retrofitting agreement after a mistake is a much harder conversation.
Days 66–80: deploy assembly on tier 3 only. Rep emails, from approved modules, with claim text locked and assembly logged. Tier 3 only. The temptation to extend upward should be resisted until the log has been audited at least once.
Days 81–90: audit your own trail. Pick twenty sent emails at random and reconstruct each one - which modules, which versions, which references, who approved them, when. If you cannot reconstruct all twenty, the logging is inadequate and must be fixed before scaling. Better to discover this at twenty than at twenty thousand.

The step teams want to skip

Days 1 to 35- the claim audit and the library. It is administrative, it produces nothing demonstrable, and there is always pressure to start with the visible AI capability instead. Skipping it does not save time; it relocates the work into the review queue, one asset at a time, forever. A claims library is the only thing that converts AI from a content generator into a content accelerator, and there is no version of this that works without one.

Seven ways this goes wrong

Generating claims instead of assembling them. The foundational error. Produces fluent unapproved material and fills the review queue with work that is slower than what it replaced.
Believing the claims-check marketing. Buying a tool on the understanding that it verifies claims against references when it checks that a reference is attached. Ask the question in the callout above.
Automating the easy checks and expecting the queue to clear. Reviewer time was never mostly spent on spelling. Structural automation is worth having and will not release the constrained resource on its own.
No assembly log. Content goes out that nobody can reconstruct afterwards. This is the failure that turns a manageable finding into an unmanageable one, because the answer to "what did you send this doctor" becomes "we do not know".
Letting tier 3 absorb tier 2 work. A new claim slipped into an assembled email because the deadline was tight. The rule that any unapproved claim escalates the tier exists precisely for this, and it needs enforcement in the interface rather than in the policy document.
Unmaintained library. Modules whose references have been superseded remain selectable. Reference version control and automatic expiry are not optional extras - they are what stops the library becoming a liability over time.
Treating non-promotional as a label rather than a determination. Material is non-promotional because of what it contains, not because of what it is called. Tier 4 is the most abused tier in every governance model we have seen.

What a module actually looks like

The abstraction becomes much easier to specify once you see the record. A module is not a paragraph in a folder - it is a structured object with mandatory fields, and the fields are what make automated assembly safe.

Field	Example value	Why it is mandatory
Module ID	CLM-EFF-014-v3	Stable identifier carrying the version. Logged on every assembly this is what makes reconstruction possible
Type	Clinical efficacy claim	Determines which assembly slots it can fill and which review path it took
Approved text	The exact wording, locked	The claim as approved. Not a template, not a guideline the literal string that may be used
Linked reference	Study citation with document ID and version	The evidence. If the reference up-versions, this module must be revalidated or flagged
Approval record	Medical, legal, regulatory sign-off with names and dates	The audit trail. Answers who approved this and when
Markets cleared	India, UAE	A claim approved in one market is not approved everywhere. The most common cross-border failure
Specialty and audience	Cardiology, specialist	Drives AI selection. A module cleared for specialists should not surface for a general physician
Mandatory companions	Must appear with SAF-003 safety block	Enforces fair balance structurally. The system will not assemble the claim without its safety companion
Expiry	Date, or on reference supersession	Removes the module from selection automatically rather than flagging it for someone to notice
Channel constraints	Email, e-detail. Not permitted in WhatsApp	Character limits and channel rules differ, and a claim truncated mid-sentence is a different claim

Two of these fields do disproportionate work and are the ones most often omitted from a first build.

Mandatory companions. This is how fair balance becomes structural rather than editorial. If an efficacy claim cannot be assembled without its paired safety block, the most consequential MLR judgement is enforced by the system on every single assembly, rather than being re-evaluated by a reviewer each time. It does not replace the human fair-balance judgement it makes that judgement once, at module level, and then holds it.
Markets cleared. A global content library without market clearance per module will eventually push a claim approved in one jurisdiction into a market where it is not. This is the failure that generates regulatory correspondence, and it is entirely preventable with one field.

A useful sizing expectation

Teams consistently overestimate how many modules they need. In practice a single brand usually runs on forty to eighty modules covering its full promotional output across channels a handful of efficacy claims, a smaller set of safety blocks, a dozen openings and calls to action, and channel-specific variants of each.

That is a fortnight of structured work, not a year-long programme. The reason it feels larger is that the claims have never been counted, and the asset library looks like several hundred pieces. Counting them first is what makes the scope credible to a sponsor.

How to tell whether the programme is working

Four measures. Report the first two monthly from the start, because they are the ones that move early and justify continuing.

Measure	What it tells you	Target direction	Watch for
Single-cycle approval rate	What share of assets are approved without a review round trip	Rising toward the reported 75% benchmark for mature modular programmes	The clearest single indicator that the library is working. If it is flat, modules are not actually pre-approved
Module reuse rate	Average number of assets each module appears in	Rising. Around 40% more content reuse is the reported gain	A library where most modules are used once has become an archive of bespoke content
Review cycle time	Days from submission to approval, by tier	Falling, most sharply in tier 3	Measure by tier. A blended number hides whether tiering is working
Assembly reconstruction rate	What share of sent assets can be fully reconstructed from the log	100%, and nothing less is acceptable	This is the compliance measure. Audit twenty at random each quarter

The fourth measure is the one to protect. The first three are efficiency metrics and will get attention naturally because they make the programme look good. Reconstruction rate is the one that matters if anything goes wrong, it will never be requested by a stakeholder, and it is the difference between a finding that is manageable and one that is not.

Frequently Asked Questions For MLR-Compliant GenAI Content for Pharma

Yes, with an architectural constraint. The safe pattern is assembly rather than free generation: maintain a library of pre-approved modular claim blocks, each linked to its supporting reference, and use AI to select, sequence and personalise within that approved vocabulary. Free generation of promotional claims is not safe, because a generated claim is an unapproved claim however well it reads, and it enters the review queue with no provenance a reviewer can rely on. AI is legitimate at the drafting, assembly and pre-check stages; it is not appropriate for deciding what may be claimed.

Pre-approve email modules opening, clinical message variants, safety statement, call to action, sign-off each individually MLR-approved with its reference linked. AI then selects and sequences modules for the specific doctor and adapts only non-claim connective text. Three controls make it defensible: lock claim text in the interface so it cannot be edited rather than merely should not be, log every assembly with module versions and references, and expire modules automatically when their supporting reference is superseded so withdrawn claims stop being selectable. Because no new claim is created, review scope narrows to assembly and context rather than substantive re-verification.

Partly, and the boundary matters more than the capability. AI reliably automates editorial checks, risk-phrase and absolute-claim detection, boxed warning and safety information presence, required link validation, accessibility and brand format rules. It does not reliably verify that a cited reference supports a claim as worded, and it does not assess fair balance both remain human expert judgement, and published analysis of AI in MLR is explicit about this. The practical test when evaluating a tool is to ask whether it verifies claim-to-reference support or verifies that a reference is attached. Those are very different products described in similar language.

Modular content means assembling promotional material from pre-approved, independently reviewed components a clinical efficacy statement, a safety snippet, a product description, a graphic held in a claims library with each claim linked to its supporting reference. It matters for AI because it creates the constrained vocabulary that makes assembly safe: the model selects among approved options rather than generating new ones, so risk is bounded by the library. Reported gains include around 40% more content reuse, 30% shorter approval times, 75% of approvals completed in a single review cycle, and roughly 50% faster speed to market.

No regulator has issued explicit guidance on AI-aided review. Regulators assess the compliance of the final material rather than the method used to produce it, which sounds permissive and in practice places the entire burden on your documentation. You must be able to demonstrate that a qualified person made the final approval decision, that AI outputs were verified rather than accepted particularly on claims and what the AI actually did, logged and attributable. Documenting AI usage is currently framed as governance best practice rather than a mandate, but it is the first thing anyone will ask for.

Reported figures are substantial but come mainly from the modular architecture rather than from AI alone, and the distinction is worth preserving. Organisations report roughly 30% shorter approval times and 75% of approvals completed in a single cycle from modular content, and a 57% reduction in review cycle time overall. Veeva estimates its AI agents can deliver up to a 75% reduction in review cycles, with agents available from late 2025. The saving comes from not re-reviewing approved claims, which is an architectural gain that AI accelerates rather than creates.

Yes, and for a structural reason rather than a regulatory one. Published guidance assumes a mature, formalised MLR function with dedicated reviewers, a content platform, version control and an automatic audit trail. Where review is less formalised a brand manager and a medical advisor working in email and shared folders introducing generative AI raises content volume sharply while the mechanism that would catch a problem does not exist. Build the claims library and the audit trail before deploying the generation capability. The compensating advantage is real: a company building governance now can build it AI-ready rather than retrofitting AI onto a document-based process.

The company, and specifically the qualified people who approved the material. AI assistance does not transfer accountability, and no regulator or code framework treats "the tool suggested it" as a defence. This is why the audit trail requirement is not administrative overhead it is the evidence that a named, qualified human reviewed and approved, which is the thing that must be demonstrable. It is also why claim text should be locked in the interface rather than governed by policy: the control that survives a deadline is the one that is technically enforced.