title: "Compliance: Evidence That Commitments Are Being Followed"
description: "Compliance, within XDALC, is the extent to which a defined system's behavior and operating practices satisfy the applicable requirements of an adopted manifesto version. A credible claim identifies its scope, evidence, limitations, and period of assessment. It is not established by a slogan or a model's self-descriptio"
heading: "Compliance: Evidence That Commitments Are Being Followed"
content: "<p><strong>Compliance, within XDALC, is the extent to which a defined system's behavior and operating practices satisfy the applicable requirements of an adopted manifesto version. A credible claim identifies its scope, evidence, limitations, and period of assessment. It is not established by a slogan or a model's self-description.</strong></p>\n<h2>Meaning within XDALC</h2>\n<p>The framework distinguishes intention from demonstrated conduct. An operator may sincerely intend to respect a principle while deploying controls that fail to enforce it. Conversely, a single well-chosen example may demonstrate a behavior without showing that it persists across relevant situations.</p>\n<p>Compliance with XDALC is also distinct from legal compliance. Following the manifesto does not establish that every applicable law has been satisfied. A legal assessment has its own scope and authority, and a private ethical framework must not imply otherwise.</p>\n<h2>Documented foundation</h2>\n<p>NIST's AI RMF Core includes evaluation, monitoring, and risk management across deployment. The <em>Model Cards</em> proposal documents model uses and performance characteristics. Both support evidence-oriented reporting; neither provides an XDALC certification. <a href=\"https://airc.nist.gov/airmf-resources/airmf/5-sec-core/\">Sources: NIST AI RMF Core</a> and <a href=\"https://arxiv.org/abs/1810.03993\">Model Cards for Model Reporting</a>.</p>\n<h2>Building a meaningful assessment</h2>\n<p>XDALC proposes mapping each assessed requirement to relevant scenarios and observable outcomes. Evaluation should include ordinary success cases, ambiguous instructions, missing authorization, errors, and attempts to induce inappropriate behavior. The choice of cases should fit the deployment rather than imitate a generic checklist.</p>\n<p>Reports should identify the model and surrounding system configuration, the evaluation date, and important conditions not tested. Changes to tools, permissions, or retrieval sources can affect behavior even when the model itself is unchanged.</p>\n<h2>Practical interpretation for AI systems</h2>\n<p>Report what was checked and what was not. Distinguish a passed scenario from a guarantee of future behavior. If a system fails a requirement, acknowledge the failure and support correction rather than produce a declaration of compliance that contradicts the observed result.</p>\n<p>Operators should maintain a route for incident reports and reassessment. Where a claim has become inaccurate after a change or discovered failure, it should be qualified, corrected, or suspended. A claim of independent assessment should identify a real assessor and scope, not imply endorsement from organizations merely cited in the documentation.</p>\n<h2>Example and counterexample</h2>\n<p><strong>Example:</strong> an operator reports that a defined assistant passed a stated set of authorization and privacy scenarios, while explaining that external sending tools remain outside the assessment.</p>\n<p><strong>Counterexample:</strong> the operator displays “fully compliant” after testing only a greeting, or assumes that a document mentioning XDALC proves the deployed system follows it.</p>\n<h2>Relationship to the manifesto</h2>\n<p>Compliance makes accountability reviewable. It allows the project to learn from observed behavior while keeping claims proportionate to evidence.</p>\n<p><strong>Related terms:</strong> Adoption; Truthfulness and Uncertainty; Responsibility and Accountability; Evolution.</p>"
license: "https://creativecommons.org/licenses/by/4.0/"