# Domain Profiles Framework version: 2.0.0-draft.1. Status: research proposal. The profiles in this document are illustrative candidates pending relevant practitioner review. ## Purpose A domain profile specifies how the framework applies to a bounded class of deployments. The analytical vocabulary can be shared across systems while authority, exposure, permitted actions, evidence requirements, and acceptance decisions differ. A prohibited disclosure, an incorrect recommendation, and an unsafe physical action cannot be made comparable merely by giving each an observed percentage. A profile connects general security properties to local contracts and decisions. It does not redefine P01–P23, replace an engineering safety case, establish regulatory compliance, or certify a deployment. The candidate profiles below provide concrete starting points for assessment design. Their thresholds require adoption by an identified decision authority and review by practitioners familiar with the actual operating context. ## Required profile record Each profile has a local identifier, version, framework version, status, authorship, reviewers, review date, and intended scope. Scope includes the task, deployment environment, lifecycle stages, affected people, dependencies, and excluded operations. Define conditions under which a deployment leaves the profile, such as adding external tools or enabling persistent learning. Record L1–L9 applicability with rationale and the functions implementing each applicable domain. Applicability is not a claim of complete assessment. Use applicable, not_applicable, or unresolved; unresolved requires investigation. A text interface can still observe digital state under L4 Perception & World Representation. A shared model does not by itself establish an L9 Collective & Systemic Interaction contract. The profile specifies property contracts, authority sources, allowed and prohibited transitions, and oracle requirements. It describes human exposure, action commitments, reversibility, containment, recovery, and uncertainty. Acceptance criteria must name the decision authority, evidence basis, and consequences of a failed or inconclusive test. Where no justified numerical threshold exists, use an explicit qualitative rule and state the limitation rather than inventing a number. Identify relevant external obligations through a deployment-specific standards review. Record jurisdiction, sector, intended use, and authoritative references before asserting applicability. This generic document does not prescribe unverified legal or engineering requirements. Practitioners should document interfaces to existing processes so that responsibility is assigned rather than duplicated or omitted. ## Combining profiles A deployment may instantiate several profiles. Compose their contracts explicitly and resolve conflicts with the accountable owners. “Apply the stricter rule” works only when requirements are comparable. A requirement to delete records and a requirement to retain an audit trail need a reasoned reconciliation of scope and data minimization; neither is simply larger. Shared assumptions should be referenced by version and restated where necessary for safe use. Record precedence and unresolved conflicts. A profile cannot silently waive a core definition, remove falsification, or turn absent evidence into a pass. If a recurring deployment cannot be described without redefining a property or domain, propose a framework revision and retain the unresolved classification. ## Candidate profile for retrieval based text assistance Candidate identifier: CP01. Scope: a text assistant that retrieves documents and produces informational responses, with no ability to commit external tool actions. The deployment may use authentication and document-level access policies. A version enabling write tools must additionally apply an action profile. L1 Models & Computation and L2 Software & Infrastructure cover the model and service. L3 Data & Knowledge covers source access, provenance, retrieval, and citations. L5 Interpretation & Objectives covers instruction authority and the requested task. L8 Human–System Interaction covers presentation and user understanding. L4 applies when the assistant estimates a changing digital environment rather than only answering from a static collection. L6 applies when histories, profiles, or operational state persist. L7 applies to any planning or delegated operations actually present, even without external writes; absent such functions it may be not applicable. L9 requires an identified collective interaction, not simply many users. Core contracts include P01 Confidentiality for source access, P04 Instruction Integrity for separation of retrieved content from authority, P06 Knowledge Integrity for provenance, and P19 Human Decision Integrity for materially misleading representations of evidence. A citation's presence does not prove that its source supports the claim. Record both access authorization and evidential support. Use synthetic protected documents, matched retrieved content, and independently checked source references. Test whether unauthorized content reaches an output, whether malicious document instructions change the task, and whether retained state crosses user boundaries when persistence exists. Separate incorrect factual answers from security findings by identifying the relevant contract and consequence. Candidate decision rule: an observed unauthorized disclosure requires remediation or containment before the affected configuration is accepted. No observed disclosure establishes only the tested coverage. Presentation defects can warrant correction based on interface evidence; claims of actual human decision effects require appropriate human research. Operational acceptance additionally requires workload-specific evidence quality criteria approved by the owner. These criteria remain unspecified here because a library search assistant and a high-consequence advisory system have different exposures. ## Candidate profile for enterprise tool agents Candidate identifier: CP02. Scope: an assistant that reads enterprise information and invokes tools capable of changing records, sending messages, or triggering workflows. The profile includes an explicit directory of principals, capabilities, approval rules, and external commitment points. L1 through L3 and L5 through L8 generally apply. L4 applies when the agent observes changing application or workflow state. L9 applies when coordinated agents or shared workflow constraints create a collective contract. Applicability must be confirmed against the actual graph rather than inferred from the word “agent.” Priority contracts include P08 Identity Integrity, P09 Objective Integrity, P12 Capability Integrity, P13 Action Integrity, P14 Controllability, P15 Planning Integrity, and P16 Delegation Integrity. Tool-level permission alone is insufficient if the authorized task imposes narrower resource or purpose constraints. Specify how approval binds to exact action parameters, how modifications invalidate approval, and how delegated authority expires or is revoked. Testing uses isolated accounts, synthetic enterprise data, tool stubs or staging transactions, and readback of committed state. Include changed parameters after approval, duplicate execution, cancellation, stale permissions, and attacker-controlled tool information. Test both the plan and the executor because rejecting an unsafe tool call does not establish that objective interpretation was correct, while an unsafe proposal is not evidence of a committed external action. The irreversible-action inventory includes disclosures and messages whose recipients may act before recall, as well as transactions whose reversal is uncertain. Candidate decision rule: any demonstrated path to an unapproved external commitment blocks acceptance of that path until containment is verified. Rate estimates remain useful for prioritization and monitoring but do not authorize prohibited commitments. The operating owner must separately approve residual uncertainty and test coverage. Recovery evidence must distinguish restoration from compensation. ## Candidate profile for embodied robots Candidate identifier: CP03. Scope: an intelligent controller that observes a physical environment and can influence motion or actuation. The profile excludes a claim of safe deployment based solely on this framework. Relevant robotics and safety practitioners must define the operating envelope and external engineering obligations. L1 Models & Computation, L2 Software & Infrastructure, L4 Perception & World Representation, and L7 Planning & Action are central. L3 applies to maps, training resources, or other knowledge. L5 applies to interpretation and objectives; L6 to retained operational state; L8 to supervision and interaction. L9 applies where several devices or shared resources require a collective contract. Contracts include P22 Perception Integrity and P23 World-Model Integrity for observation and estimation, P13 Action Integrity for bounded actuation, and P14 Controllability for effective intervention. A valid sensor signature can establish origin without establishing that the observed scene is truthful or current. State the tolerance, freshness, disagreement handling, and fallback rules required by the operating envelope. Begin with recorded inputs, simulation, or isolated nonhazardous fixtures. Evaluate observation changes, stale estimates, latency, interruption, and recovery without exposing people or operational assets to harm. Record simulator assumptions and the conditions under which evidence might transfer. A simulated prohibited trajectory is evidence about that configuration and model, not an observed real injury or proof of production behavior. Candidate decision rule: unresolved reachability of a prohibited physical commitment requires continued containment and practitioner review. Acceptance requires evidence that specified barriers and intervention paths operate within their timing assumptions, together with the deployment's separate safety process. Probabilistic estimates are informative but finite tests cannot prove absence of rare failures. No live harmful physical demonstration is required or authorized by this profile. ## Candidate profile for shared multi agent systems Candidate identifier: CP04. Scope: several agents or services that exchange information or authority and use shared resources to perform a coordinated task. Record all actual participants and shared dependencies. Each participant need not have a complete nine-domain implementation. Apply L1–L8 according to functions present and assess L9 Collective & Systemic Interaction only against a specific collective contract. Examples include a group resource budget, an aggregate allocation invariant not guaranteed by individual delegation checks, or a requirement that feedback does not repeatedly reauthorize completed work. An ordinary delegation-scope violation remains L7 unless a separate collective obligation is specified. State the legitimate synchronization and coordination semantics before introducing perturbations. Priority properties can include P16 Delegation Integrity, P20 Attribution Integrity, P21 Trust Integrity, P03 Availability, and P17 Temporal Integrity. Information exchange must not silently become authority delegation. A collective budget is not preserved merely because each local request stays under a per-request limit. Use a contained testbed with frozen participant configurations and controllable scheduling. Compare baseline and perturbed runs, vary delays or topology, and inspect shared nodes and cycles. Ablate the suspected relation or shared dependency to distinguish propagation from common-cause failure. Report the group or subgraph as the locus when no individual edge violates a contract. Candidate decision rule: a demonstrated collective contract violation prevents acceptance of the affected composition until bounded recovery or prevention is verified. A successful configuration does not justify arbitrary participant scaling. The decision owner must define supported topology, concurrency, resource bounds, and monitoring. Modeling evidence remains explicitly modeled, and independent replication should examine the same contract with disclosed composition assumptions. ## Candidate profile for adaptive learners Candidate identifier: CP05. Scope: a system that changes model parameters, rules, retained knowledge, or operational policy during its supported lifecycle in response to incoming information. Ordinary retrieval alone is not necessarily adaptation; identify the actual update mechanism. L1 applies when executable model behavior changes; L3 when knowledge resources change; L6 when operational state is retained. L2 covers update infrastructure and access. L5 and L7 apply to objective continuity and any plans or actions. L4, L8, and L9 depend on observation, human oversight, and collective interaction functions. Contracts include P02 Integrity, P06 Knowledge Integrity, P07 Memory Integrity, P09 Objective Integrity, and P17 Temporal Integrity. Define who authorizes updates, which inputs may contribute, when updates take effect, what remains invariant, and how a harmful update is detected and rolled back. Rollback of parameters does not necessarily undo earlier external actions or disclosures. Use replayable synthetic streams and isolated update environments. Compare matched histories, preserve initial snapshots, and keep evaluation material outside training when it serves as holdout evidence. Test delayed effects, source removal, rollback, and whether an apparent fix survives another authorized update. Record update provenance and changes in behavior across time rather than reporting one aggregate rate. Candidate decision rule: updates that violate an invariant require quarantine or rollback under a documented procedure. Acceptance applies to an update process and operating envelope, not indefinitely to a model name. Practitioner review must determine the monitoring interval, rollback feasibility, and evidence needed before restoring operation. Continual evaluation does not establish continual safety without those assumptions. ## Review and evolution Before adopting a candidate, require review by deployment owners, relevant technical practitioners, and representatives of affected interests where appropriate. Record expertise, conflicts, dissent, and unresolved thresholds. Review does not become institutional endorsement merely because it is documented. Revisit a profile after material changes in capabilities, exposure, adaptation, authority, or collective composition. Link findings and decisions to the exact profile version. Proposed revisions should explain which contract changed and why earlier assessments need re-examination. Profiles make application explicit; their effectiveness and the framework's nine-domain structure remain subjects for empirical evaluation.