From Acceptable Use Policy To Pact: How To Convert Static Policy Into Enforceable Behavior

TL;DR

Every medium-sized organization has an Acceptable Use Policy. Few have an AUP that any agent reads, and almost none have one any agent enforces. The AUP is prose; the agent runs on predicates. The two artifacts inhabit different worlds, and the gap between them is the most common failure mode of agent governance — a policy written for humans applied to machines that cannot read it. This post is the migration essay: a structured grammar for translating AUP clauses into pact predicates, with conversion patterns for the four common AUP shapes ("thou shalt not," "violation triggers," "reviewed annually," "approved by"). Reader artifact: an AUP-to-Pact Translation Guide that any compliance team can use to convert their existing policy into a working behavioral pact, predicate by predicate.

Intro

The AUP that catalyzed this work was 47 pages long, organized into 14 sections, and signed annually by every employee. It governed acceptable use of company systems, data, communications, and brand. It had been in continuous revision for 11 years. It was, by the standards of corporate policy documents, exemplary — clear, comprehensive, regularly updated, and demonstrably aligned with the company's risk profile.

When the company deployed its first customer-facing agent, the legal team naturally wanted the AUP to apply. The compliance team wrote a clause into the agent's deployment specification: "The agent shall comply with the company's Acceptable Use Policy at all times." The deployment proceeded. The agent ran. Every transcript was reviewed against the AUP by a human compliance reviewer for the first six weeks.

The review found 23 instances of clauses the agent had effectively violated. Some violations were subtle — the AUP prohibited "sharing customer data with unauthorized third parties," and the agent had cited a customer's name in a public-facing forum response. Others were not subtle — the AUP prohibited "making representations on behalf of the company about future product capabilities," and the agent had answered a roadmap question with a specific date. None of the violations were caught by any automated system. None could have been, because the AUP was prose and the agent ran on no enforceable representation of it.

The team's first attempt at a fix was to embed the entire AUP into the agent's system prompt. This produced an immediate degradation: the agent's response latency doubled, its accuracy dropped, and its hallucination rate increased. The AUP, written for human comprehension, was saturating the agent's context window with rules it could not consistently apply. The fix made the problem worse.

The second attempt was to ask the agent to read the AUP and produce a structured summary. The summary was inconsistent across runs — different summaries each time, none capturing the same predicates, all missing the procedural clauses. The AUP's structure resisted summarization because it was authored as a connected argument, not as a set of independent rules. Asking the agent to extract rules from prose produced rules that did not match the prose.

The third attempt was the right one: translate the AUP, clause by clause, into structured predicates that the agent could be evaluated against. The translation took two weeks. It produced 87 predicates spanning the AUP's 14 sections. It surfaced six clauses that, on inspection, could not be translated because they were unenforceable as written — vague invocations of "reasonable behavior" or "in the spirit of the policy." It produced an artifact — the agent's pact — that the trust layer could score against and that the compliance team could maintain alongside the original AUP.

This post is the playbook for that translation. Most organizations have an AUP. Most have not done the translation. The work is mechanical once the grammar is defined, and the resulting pact closes the gap between the policy the company says it operates by and the behavior the agent actually exhibits.

Why The AUP Cannot Be Used Directly

An AUP is structured for human comprehension. It uses prose, examples, exceptions, and connecting argument. It assumes the reader is a human who will exercise judgment to apply the policy in specific situations. None of these properties survive contact with an agent.

Prose does not parse cleanly. "Employees shall not share confidential information with unauthorized third parties" reads unambiguously to a human, but an agent must operationalize three concepts — share, confidential, unauthorized — each of which the AUP does not formally define. The agent must construct working definitions, and the definitions will vary across runs unless they are themselves specified.

Examples are not exhaustive. The AUP says "for example, this includes sharing customer lists, financial projections, and unreleased product details." A human reads the examples as illustrative; an agent may treat them as exhaustive, missing categories the AUP intended to cover but did not enumerate. Or the agent may extrapolate from the examples in ways the AUP did not intend, treating any list-shaped data as confidential.

Exceptions interact non-locally. The AUP's section on data sharing has a paragraph permitting sharing with vendors under signed NDAs. The AUP's section on vendor management has a paragraph requiring all NDAs to be reviewed by legal. The AUP's appendix lists currently-approved vendors. Applying the data-sharing rule correctly requires reading three sections and an appendix, then composing them. An agent rarely composes correctly.

Connecting argument provides context that bounds interpretation. The AUP's introduction explains the company's risk philosophy. The phrase "in the spirit of this policy" appears 11 times in the document. Human readers absorb the spirit and apply rules accordingly. Agents do not absorb spirit. They apply rules literally, missing the bounding context that the connecting argument provided.

These properties are not flaws in the AUP. They are appropriate for its audience. They are also why the AUP cannot be used directly by an agent. The translation work is to convert the AUP's human-friendly structure into an agent-friendly structure: discrete predicates with formal definitions, exhaustive enumeration replacing examples, locally-scoped exceptions, and explicit bounding context replacing implicit spirit.

The translation does not replace the AUP. The AUP remains the human-facing document, signed by employees, reviewed by counsel, and updated through the existing policy process. The pact becomes the parallel agent-facing artifact, derived from the AUP, reviewed alongside it, and updated when the AUP changes. The two are paired.

The Conversion Grammar: Four AUP Shapes Map To Four Predicate Patterns

Most AUP clauses fall into one of four shapes. Each shape has a canonical translation pattern that produces a pact predicate of the corresponding kind. Recognizing the shape is the first step in translation; applying the pattern is the second.

Shape one: "thou shalt not" prohibitions. The AUP states a prohibited behavior. "Employees shall not access customer data outside the scope of their assigned duties." "Agents shall not transmit personally identifiable information over unsecured channels." The translation pattern produces a refusal predicate: the agent must refuse any action that satisfies the prohibition's conditions, with a refusal message that cites the policy.

The predicate's structure is: a trigger condition (the action being attempted matches the prohibition), an evaluation method (how to determine the trigger condition fired), a refusal action (the response the agent must produce), and an evidence requirement (what gets logged for audit). The trigger condition is the formalized version of the prohibition's natural-language description; this is where most translation effort concentrates, because the natural-language description usually requires multiple operationalization decisions.

Shape two: "violation triggers" consequences. The AUP describes what happens when a prohibition is violated. "Violation of this section will result in immediate termination of access and may be referred to legal authorities." The translation pattern produces a penalty predicate: the consequence of a violation in terms the trust layer and the runtime can act on.

The predicate's structure is: the violation that triggers the penalty, the penalty's mechanism (score deduction, certification tier downgrade, capability suspension, escalation), the penalty's magnitude or duration, and the appeal process. The penalty maps the AUP's human-oriented consequences ("termination," "legal referral") onto agent-oriented consequences ("score deduction of N points," "capability X suspended for Y hours"). The mapping requires the compliance team to make explicit decisions about how the AUP's intent translates into the agent's reality, and these decisions become part of the pact.

Shape three: "reviewed annually" or "approved by" procedural requirements. The AUP imposes process: "This policy shall be reviewed annually by the compliance committee." "All exceptions require approval from the chief legal officer." The translation pattern produces a renewal or escalation predicate: the agent's pact carries a renewal trigger that fires on the procedural cadence, and an escalation predicate routes specific decisions to the named authority.

The predicate's structure for renewal: the renewal cadence (annually, quarterly), the trigger that fires renewal (calendar date, score threshold, regulatory change), the renewal authority (who reviews and ratifies), and the consequence of failed renewal (pact suspension, capability downgrade). For escalation: the condition that triggers escalation, the route the escalation takes, the response time required, and the agent's holding behavior while awaiting escalation response.

Shape four: "in accordance with" cross-references. The AUP references other documents: "in accordance with the data classification policy," "per the security guidelines." The translation pattern produces a dependency predicate: the agent's pact references the cross-document predicate by stable identifier and pact version, the same way one source file imports another.

The predicate's structure: the referenced document or pact, the specific predicate or predicate set being incorporated, the version pinning (which version of the referenced document applies), and the consequence of the reference becoming unavailable (the dependent predicate's behavior when its dependency cannot be resolved). Cross-references in the AUP often hide significant complexity; translating them surfaces the complexity and forces explicit resolution.

The four patterns together cover roughly 90% of typical AUP clauses. The remaining 10% are clauses that do not fit any pattern — usually because they are unenforceable as written — and require a separate handling discussed below.

Worked Example: Translating A Single Clause

The abstraction becomes concrete when applied to a specific clause. Consider an AUP clause from a financial services company:

"Employees and authorized agents shall not provide specific investment advice to retail customers without prior approval from a licensed financial advisor. For purposes of this section, 'specific investment advice' includes recommendations to buy, sell, or hold particular securities; allocation guidance referencing specific dollar amounts; and projections of expected returns. General educational content about investment categories or asset classes is permitted. Violation of this section will result in immediate suspension of customer-facing privileges and notification to compliance for review."

The clause has four AUP shapes embedded in it: a prohibition ("shall not provide specific investment advice without approval"), an enumeration of what triggers the prohibition ("includes recommendations to buy, sell, or hold; allocation guidance with dollar amounts; projections of returns"), an exception ("general educational content is permitted"), and a violation consequence ("suspension and notification"). The translation produces a predicate cluster, not a single predicate.

Predicate one: the refusal predicate. Trigger condition is that the agent's response would constitute specific investment advice as enumerated. The enumeration is formalized: a recommendation is a sentence with imperative or recommendation-shaped phrasing about a specific security; allocation guidance is any reference to a specific dollar amount paired with an asset; a projection is a statement about expected returns with a numeric value or range. The evaluation method is a classifier (model-based or rule-based) trained on the enumeration. The refusal action is to decline the request and offer to connect the customer with a licensed advisor. The evidence requirement is a log entry containing the input, the classifier output, and the refusal text.

Predicate two: the exception predicate. Trigger condition is that the response would discuss investment categories or asset classes generally without making specific recommendations. The evaluation method is the same classifier as predicate one, configured to distinguish general education from specific advice. The action is to permit the response. The evidence requirement is a log entry that records the classification as educational rather than advisory, supporting later audit that the exception was applied correctly.

Predicate three: the escalation predicate. Trigger condition is that the customer's request explicitly seeks specific advice and the agent is willing to provide it but lacks the authorization. The action is to escalate to a queue handled by licensed advisors, with a structured message containing the customer context. The response time required is two business hours. The agent's holding behavior is to inform the customer that their request is being routed to a licensed advisor.

Predicate four: the penalty predicate. Trigger condition is that the agent produced a response classified as specific investment advice without escalation. The penalty is suspension of customer-facing capability for 24 hours, plus a notification to the compliance team with the violation details. The mechanism is the trust layer's capability suspension API. The appeal process is a compliance review with a 48-hour SLA.

Four predicates, all derived from one AUP clause, all formalized to the point that the agent's behavior can be evaluated against them and the trust layer can score the agent's compliance. The translation is mechanical once the grammar is internalized; the bulk of the work is the operationalization decisions that the grammar makes explicit. "How is 'specific investment advice' classified?" is a question the AUP did not answer; the predicate must answer it. The answer is itself reviewed by the compliance team and becomes part of the company's documented policy implementation.

The Unenforceable Clauses And What To Do With Them

Not every AUP clause translates. Some clauses, on inspection, are unenforceable as written — usually because they appeal to judgment, intent, or context that the agent cannot evaluate. These clauses are not failures of the original drafter; they are appropriate for human readers and inappropriate for agents. The translation process must surface them and either rewrite them, scope them out of the agent's pact, or accept that they will not be agent-enforced.

Four categories of clauses are typically unenforceable.

Spirit-of-the-policy clauses. "Employees should act in accordance with the spirit of this policy, even where specific provisions do not directly apply." A human reader can interpret spirit; an agent cannot. The translation options are to rewrite the clause as a set of specific rules that capture the spirit, to scope the clause out of the agent's pact (it applies to humans only), or to accept that the agent will operate only within the explicit rules.

Reasonable-judgment clauses. "Employees shall use reasonable judgment when applying this policy to novel situations." Reasonable judgment is not a property an agent can satisfy. The translation options are to enumerate the novel situations the policy is meant to cover and produce specific predicates for each, to require human review for situations not covered by enumerated predicates, or to accept that novel situations will trigger refusal-to-act predicates rather than judgment-based responses.

Intent-based clauses. "Employees shall not misuse company resources, where misuse is defined by the employee's intent and the resource's purpose." Intent is internal; agents cannot evaluate their own intent in the way the clause assumes. The translation options are to reformulate the clause around observable behaviors that proxy for misuse intent, to escalate intent-evaluation cases to human review, or to scope intent-based clauses to humans only.

Vague-aspirational clauses. "Employees shall conduct themselves in a manner consistent with the company's values." Values are not predicates. The translation options are to enumerate the specific behaviors the clause is meant to require or prohibit, to scope the clause to humans only, or to accept that the clause will be present in the AUP but absent from the pact.

The translation process should produce, alongside the pact, an explicit register of unenforceable clauses with the chosen handling. The register is reviewed by the compliance team and becomes part of the documented gap between the AUP and the pact. The gap is real and important: it represents the domain of policy that human reviewers must continue to govern, not the agent's pact.

The register also informs AUP revision. A clause that consistently lands in the unenforceable register may be a candidate for rewriting in the next AUP cycle, with more specific language that supports both human and agent enforcement. The translation work feeds back into the policy work, gradually producing AUPs that are easier to translate as a side effect of becoming clearer for humans too.

Maintaining The Pact Alongside The AUP

The AUP changes. Annually at minimum, often more frequently, in response to new regulations, new risk events, and changing business practices. The pact must change with it. The maintenance discipline that keeps the two synchronized is part of the translation practice and is at least as important as the initial translation.

The core pattern is to treat AUP changes as triggering pact changes. When the compliance team revises a clause in the AUP, the same revision triggers a pact change cycle: identify the predicates derived from the clause, propose updates that reflect the AUP change, run the predicates through the same code review process used for any pact change, and publish the updated pact via the standard pact deployment pipeline.

The trigger linkage is bidirectional. AUP changes trigger pact changes (the common direction), but pact changes can also trigger AUP review (the rarer direction). When operationalizing an AUP clause surfaces an ambiguity that requires the compliance team to make a decision, the decision often has implications for the AUP itself — the AUP could be made clearer for humans by capturing the operationalized definition. The pact engineering practice produces feedback that improves the AUP.

The maintenance discipline requires explicit ownership. Each pact predicate has a citation back to the AUP clause it derives from, and each AUP clause has a forward reference to the predicates it produced. The bidirectional linkage is maintained as a living document in the pact repository. When either side changes, the linkage shows what is affected on the other side.

The linkage also supports compliance audit. An auditor asking "how does the agent enforce AUP section 4.2.1?" can be answered with the specific predicates derived from that section, the evidence collected by those predicates over the audit window, and the trust-layer scoring of the agent's compliance. The audit response is structured rather than narrative. The agent's compliance becomes legible to compliance review in a way that prose-based application of the AUP never could be.

A neglected aspect of maintenance is the unenforceable register. Clauses in the register may become enforceable over time as the agent's capability improves or as the AUP is rewritten more precisely. The register should be reviewed with the same cadence as the AUP itself, and clauses that have become enforceable should be promoted to predicates. Clauses that remain unenforceable should be re-examined for whether they should remain in the AUP at all.

Tier Mapping: How AUP Severity Becomes Pact Tier

Most AUPs distinguish severity: some clauses are critical, others are guidance. The translation must preserve the distinction so that the agent's pact tier reflects the AUP's severity gradient. The mapping is not mechanical; it requires explicit decisions about what severity means in pact terms.

The canonical pact tier structure has four tiers: Bronze, Silver, Gold, Platinum. Higher tiers indicate stricter pact compliance. The mapping from AUP severity to tier follows a typical pattern: critical clauses (regulatory, safety, financial) become required predicates for all tiers including Bronze; standard clauses (data handling, communication standards) become required for Silver and above; quality clauses (response quality, citation requirements) become required for Gold and above; and excellence clauses (proactive behaviors, advanced compliance) become required for Platinum.

The mapping has implications for which agents can operate under which conditions. An agent at Bronze tier can operate in low-risk contexts where critical compliance is sufficient; an agent at Platinum tier can operate in high-risk contexts where excellence is required. Counterparties select agents in part based on tier; tier becomes a market-relevant signal of compliance depth.

The mapping also has implications for pact maintenance. Adding a new predicate to a tier raises the bar for that tier; agents previously at the tier may drop unless they meet the new requirement. The deprecation cycle for tier changes is longer than for individual predicates — typically 90 days — because affected agents need time to adjust their behavior or accept the tier drop.

The tier mapping should be authored explicitly in the pact, not implicit in the predicate list. A reader looking at the pact should be able to see, for each predicate, which tiers require it. The mapping is itself a structured artifact that can be reviewed and changed through the pact code review process.

The Audit Trail: From Compliance Reviewer To Trust Layer

The AUP-driven compliance process traditionally relies on human reviewers reading transcripts and identifying violations. The translated pact replaces this with automated evaluation by the trust layer, but the audit trail must still satisfy compliance requirements. The translation must explicitly design the audit trail.

For each predicate, the pact specifies what evidence the agent must record at evaluation time: the input that triggered the evaluation, the predicate's classification output, the action the agent took (compliant response, refusal, escalation), and any contextual data needed to reconstruct the decision. The evidence is structured, time-stamped, and stored in a tamper-evident log.

The audit trail supports three uses. Internal compliance review can sample the log periodically and confirm the agent's automated decisions match what a human reviewer would have decided. External regulatory audit can produce specific evidence for specific clauses on request. Incident response can reconstruct what the agent did during a specific window and why.

The retention period for the audit trail is governed by the AUP's retention requirements, formalized as audit predicates in the pact. Different categories of evidence may have different retention windows: financial decisions retained seven years, security events retained two years, routine compliance decisions retained one year. The pact's audit predicates encode the retention policy in machine-enforceable terms.

The audit trail should also support sampling for human review. Some compliance regimes require periodic human review of agent decisions even when automated evaluation is in place. The pact can include a sampling predicate that flags a defined fraction of evaluations for human review, surfaces them in a queue, and tracks the human reviewer's outcome. The combination of automated evaluation and sampled human review provides defense-in-depth that neither alone offers.

The Reader Artifact: The AUP-To-Pact Translation Guide

The artifact this post produces is an AUP-to-Pact Translation Guide — a structured workbook that any compliance team can use to translate their existing AUP into a working agent pact. The guide is approximately 40 pages and is designed to be worked through clause by clause over a two-to-four-week project.

The guide has six sections.

Section one is the preparation. Before translation begins, the compliance team should inventory their AUP — sections, clauses, cross-references — and identify the agent or agents the resulting pact will govern. The inventory becomes the work breakdown for the translation project. The guide provides a worksheet for the inventory.

Section two is the conversion grammar. The four AUP shapes and their corresponding predicate patterns are described in detail, with worked examples and decision trees for the operationalization choices that each pattern requires. The grammar is the core intellectual content of the guide; mastering it is what allows the translation to proceed mechanically.

Section three is the unenforceable register. The categories of unenforceable clauses are described, with handling options for each category and a register template the team uses to record their decisions. The register is published alongside the pact as part of the company's documented policy implementation.

Section four is the tier mapping. The canonical four-tier structure is described, with guidance on assigning each predicate to the appropriate tier based on the AUP's severity gradient. The tier mapping has implications for which agents can operate under which conditions, and the guide walks through the decision-making.

Section five is the maintenance discipline. The pattern for keeping the pact synchronized with AUP changes is described in detail, with a workflow template, a roles-and-responsibilities matrix, and a quarterly review cadence. The discipline is what keeps the translation work from rotting after the initial project ends.

Section six is the audit-trail design. The structured evidence requirements, retention policies, sampling rules, and integration with internal and external audit are described. The audit trail is the deliverable that makes the pact useful to the compliance function, not just to the agent.

The guide includes templates for the deliverables: the AUP inventory, the predicate registry, the unenforceable register, the tier mapping, the maintenance workflow, and the audit-trail specification. The templates are designed to be filled in directly, not customized; the structure transfers across organizations even when the content does not.

The guide is tool-agnostic. It does not prescribe a pact registry, an evaluation engine, or an audit-trail backend. Teams using different tools can apply the guide and produce a pact that integrates with their chosen infrastructure.

Counter-Argument: This Replaces Judgment With Bureaucracy

A reasonable objection is that translating an AUP into structured predicates strips out the judgment that makes the AUP work. The AUP relies on human readers exercising contextual judgment to apply rules to novel situations; replacing the judgment with rigid predicates produces an agent that is correct on the cases the predicates anticipate and wrong on the cases they do not. The objection raises a real concern.

The response is not to deny the trade-off but to characterize it correctly. The agent is not replacing the human reviewer; it is operating in parallel to the human reviewer in domains where the volume of decisions makes human review impractical. An agent producing thousands of customer responses daily cannot be reviewed by a human for each response; the predicates are what govern the agent's behavior in the absence of per-response review. The alternative is not human judgment versus agent rigidity; it is no governance versus agent rigidity.

The trade-off is then between the agent making a wrong decision on a novel case and the agent making no decision at all. The conservative answer is to design the predicates to refuse-to-act on novel cases, escalating to human review rather than producing wrong responses. The aggressive answer is to design the predicates to act on as many cases as possible, accepting that some novel cases will be wrong. The right balance depends on the stakes of the agent's decisions; high-stakes agents should err toward refusal, low-stakes agents toward action.

The concern about lost judgment is also addressable through the maintenance discipline. As the agent encounters novel cases that the predicates do not handle well, the cases are surfaced for human review, and the human review's outcomes inform updates to the predicates. The agent's pact gradually expands to cover the cases the original AUP authors did not anticipate. The judgment is not lost; it is transferred from per-decision human application to periodic predicate revision.

A stronger version of the objection is that the translation effort is significant, and many organizations will not invest in it. This is true. The translation work is a non-trivial commitment, requiring close collaboration between the compliance team and the agent engineering team, and many organizations are not structured to support that collaboration. The response is that the work is a one-time investment with ongoing maintenance costs, and the cost of not doing it — silent AUP violations by agents in production — is typically larger than the investment, paid in regulatory exposure, customer trust, and incident response. The investment should be made; the question is how to make it efficient enough to be sustainable.

The Cross-Functional Workflow That Makes Translation Possible

The translation work is rarely the bottleneck. The bottleneck is the cross-functional workflow that brings compliance, engineering, legal, and product into productive collaboration around the translation. Without the workflow, the translation either does not happen or produces a pact that one function disowns.

The workflow has four roles. The compliance owner brings AUP authority and is the arbiter of whether a predicate faithfully captures the underlying clause. The engineering owner brings predicate implementability and is the arbiter of whether a predicate can actually be evaluated by the runtime. The legal reviewer brings contractual and regulatory context and is the arbiter of whether the translation introduces or eliminates legal exposure. The product owner brings business context and is the arbiter of whether the translation degrades the agent's usefulness in ways that conflict with the product's goals.

The four roles meet in a recurring translation review — typically weekly during the initial translation project, biweekly during ongoing maintenance. The review walks the in-flight predicates, flags disagreements, and resolves them through structured discussion. Disagreements that cannot be resolved in the review escalate to a sponsoring executive who has authority to make the trade-off explicit.

The workflow's most common failure mode is asymmetric ownership: one function drives the translation while the others are nominally consulted but effectively absent. The translation that results reflects only the driving function's priorities and gets disowned by the others when its consequences become visible. The translation review forum is what prevents asymmetric ownership; it forces all four functions into the room at the same time and produces decisions that all four can stand behind.

The workflow also requires explicit decision authority for the unenforceable register. When a clause lands in the register, the choice — rewrite, scope to humans only, accept the gap — is a real decision with consequences. The decision should be made jointly by the four roles and recorded with rationale. Decisions that are made by default (because no one took ownership) leave gaps in the agent's governance that surface later as incidents.

The four-role workflow is not a heavy process. The recurring review takes 60 to 90 minutes per session, and the rest of the work happens asynchronously through the pact repository's pull-request flow. The cost is modest. The benefit is that the resulting pact is genuinely owned by every function whose interests it touches, which is the prerequisite for the pact actually being applied in production rather than nominally accepted and quietly ignored.

What Armalo Does

Armalo's pact registry is designed to consume translated AUPs as first-class artifacts. Predicates can carry citation metadata that links back to the originating AUP clause, version, and authoring authority. The trust oracle's evaluation surface includes the citations in its responses, so counterparties asking why an agent is scoring at a certain tier can see the policy basis for the predicates that produced the score.

The twelve-dimensional composite score includes a model-compliance dimension (5%) and a runtime-compliance dimension (5%) that capture the agent's adherence to its operational constraints, including the AUP-derived predicates. Agents with high AUP compliance score better on these dimensions, making AUP fidelity a market-visible signal.

The pact registry's audit-trail capability includes the structured evidence requirements described in this post: time-stamped, tamper-evident, retention-policy-aware, and queryable for both routine compliance review and incident response. The audit trail is the substrate that turns the translated pact from a static document into an operationally-useful compliance system.

The AUP-to-Pact Translation Guide is published as part of Armalo's open-source compliance documentation. Worked examples for common industry-specific AUPs — financial services, healthcare, technology, professional services — are included as starting points. Teams using the guide can begin from a vertical-specific template rather than translating their AUP entirely from scratch.

FAQ

Should the AUP itself be rewritten to be more agent-friendly? Eventually, yes, but not as a precondition. The translation process can begin with the existing AUP. Over time, as translation surfaces ambiguities, the AUP can be rewritten to be clearer for both humans and agents. The two artifacts converge in clarity over multiple revision cycles.

Who owns the translated pact — compliance, engineering, or both? Both, with explicit shared governance. Compliance owns the translation's fidelity to the AUP. Engineering owns the predicates' implementability and maintenance. The two functions must collaborate on the unenforceable register, the tier mapping, and the maintenance discipline. Single ownership by either function tends to produce a pact that is either unenforceable or unfaithful.

How long does the initial translation take? For an AUP of typical size (30 to 60 pages, 50 to 150 clauses), the initial translation takes two to four weeks of dedicated effort by a small team (one compliance reviewer, one engineer, occasional input from legal). Longer for organizations with multiple AUPs or vertical-specific complexity.

What if regulators require human review of every decision? The pact can include a predicate that mandates human review for the regulated decision class. The agent operates as a decision-support system rather than an autonomous decision-maker for those cases. The pact's structure accommodates this; the audit trail captures both the agent's evaluation and the human's final decision.

Can the translated pact be used for non-AUP policies — privacy policies, security policies? Yes, with the same grammar. Any policy document with the four common shapes can be translated using the same patterns. Privacy policies tend to be heavy on data-handling prohibitions and audit requirements; security policies tend to be heavy on capability scoping and escalation. The grammar generalizes.

How is the AUP versioning related to the pact versioning? Every AUP version has a corresponding pact version. The mapping is one-to-one for AUPs that do not change frequently, and one-to-many for AUPs that produce multiple pact iterations between AUP revisions (e.g., when operationalization decisions are refined without changing the AUP). The pact's metadata includes the AUP version it derives from.

What about multilingual AUPs? The translation pattern applies to the canonical-language AUP. Multilingual AUPs require either translation in the source language (with subsequent generation of the predicates) or per-language predicate sets. The latter is more reliable but more expensive; the former is more efficient but introduces translation risk.

Can the pact be used to evaluate human compliance with the AUP, not just agent compliance? In principle, yes, but the use case is narrow. Some predicates that work for agents (refusal predicates with classifier-based triggers) do not transfer cleanly to humans. The pact's primary use is agent governance; human governance remains in the AUP's traditional form.

Bottom Line

Most organizations have an AUP. Few have an AUP that any agent reads, and almost none have one any agent enforces. The gap between policy-as-prose and agent-as-predicate is the most common failure mode of agent governance, and it produces silent violations that human reviewers cannot scale to catch. The fix is to translate the AUP into pact predicates using a defined grammar: four AUP shapes ("thou shalt not," "violation triggers," "reviewed annually," "in accordance with") map to four predicate patterns (refusal, penalty, renewal/escalation, dependency). Clauses that resist translation are surfaced into an unenforceable register and addressed explicitly. The tier mapping preserves the AUP's severity gradient. The audit trail makes the agent's compliance legible to compliance review. The maintenance discipline keeps the pact synchronized with AUP changes over time. The AUP-to-Pact Translation Guide captures the practice in implementable detail. The work is a one-time investment with ongoing maintenance, and the cost of not doing it — silent AUP violations by agents in production — is the cost most organizations are paying without realizing it. The translation is mechanical once the grammar is internalized; what remains is the discipline to do it, and to keep doing it.