# XII. Integration ### Part 12 — Enterprise Deployment and Integration Interfaces #### 1. Status, Objective, and Non-Executing Boundary 1.1 **Status.** This Part governs how the Platform may be deployed and integrated into enterprise environments, and how outputs (alerts, benchmarks, evidence artifacts) are delivered for use by adopters. 1.2 **Objective.** The objective is to ensure enterprise deployment is:\ 1.2.1 **safe** (privacy-minimizing; non-intrusive; rate-limited; tenant-isolated),\ 1.2.2 **auditable** (logs, lineage, and change control),\ 1.2.3 **interoperable** (standards-aligned interfaces and schemas), and\ 1.2.4 **non-executing** (inform, evidence, and govern—never command or operate). 1.3 **Hard perimeter.** The Platform and Guild:\ 1.3.1 do not provide SOC/EOC dispatch, incident command, “hands-on keyboard” response, or operational runbooks for live execution;\ 1.3.2 do not issue compliance determinations, legal conclusions, or “safe/secure” certifications;\ 1.3.3 do not steer procurement, recommend vendors, or maintain “approved lists”;\ 1.3.4 do not perform enforcement, takedown operations, censorship, or coercive moderation engineering; and\ 1.3.5 do not conduct intrusive or covert collection methods prohibited by this Charter. 1.4 **Adopter accountability.** All operational decisions remain with the adopter under its authority, policies, counsel, regulators, and accountable leadership. *** #### 2. Deployment Models and Permitted Operating Postures 2.1 **Permitted deployment models.** The Platform may be deployed in one or more of the following models, subject to handling, sovereignty, and data governance constraints:\ 2.1.1 **SaaS / shared control plane** with strict tenant isolation;\ 2.1.2 **private tenant** (single-tenant managed environment);\ 2.1.3 **self-hosted / private cloud** deployments, where supported;\ 2.1.4 **sovereign / controlled research zones** (including air-gapped or restricted connectivity) where lawful and justified; and\ 2.1.5 **hybrid deployments** with segregated workloads and controlled synchronization of non-sensitive artifacts. 2.2 **Deployment eligibility conditions.** Any enterprise deployment must demonstrate:\ 2.2.1 a lawful basis for collection and processing;\ 2.2.2 security controls appropriate to handling class;\ 2.2.3 explicit data minimization and retention commitments;\ 2.2.4 defined integration boundaries and non-execution notices; and\ 2.2.5 an incident and correction contact for evidence disputes. 2.3 **Air-gapped posture.** Where air-gapped deployments are used:\ 2.3.1 updates must be signed and verified;\ 2.3.2 artifact ingestion/export must be controlled and logged;\ 2.3.3 external connectivity assumptions must be explicit; and\ 2.3.4 replayability and reproducibility must be achievable inside the boundary. *** #### 3. Integration Patterns: Enterprise Systems and Control Planes 3.1 **Permitted integration patterns.** Integrations may be provided for enterprise systems that support detection, governance, and workflow—without the Platform exercising operational control. Typical patterns include:\ 3.1.1 **SIEM** (log/event correlation) and **SOAR** (playbook triggering by the adopter);\ 3.1.2 **ticketing and workflow** systems (e.g., incident, change, risk registers);\ 3.1.3 **GRC platforms** (controls mapping, evidence attachments, audit workflows);\ 3.1.4 **CI/CD pipelines** (pre-deployment evidence checks; supply chain integrity signals);\ 3.1.5 **SAST/DAST and vulnerability management** platforms (issue creation, deduplication, severity mapping);\ 3.1.6 **asset inventories / CMDBs** (asset association and dependency mapping);\ 3.1.7 **data catalogs** (metadata lineage and dataset governance); and\ 3.1.8 **identity/access governance** (role-based access to evidence artifacts, not operational privileges). 3.2 **Integration boundary rules.** Integrations must be structured so that:\ 3.2.1 the Platform **publishes** artifacts and signals;\ 3.2.2 the adopter **decides and executes**; and\ 3.2.3 all automation paths include an adopter-owned approval gate for consequential actions, unless the action is explicitly non-consequential (e.g., creating a ticket). 3.3 **No hidden execution.** The Platform must not:\ 3.3.1 perform remote changes to customer infrastructure;\ 3.3.2 disable services or trigger blocking actions;\ 3.3.3 push policy enforcement changes; or\ 3.3.4 conduct “autonomous remediation” beyond advisory artifacts and templated evidence outputs. *** #### 4. API Constitution: Endpoint Families, Versioning, and Auditability 4.1 **API constitution requirement.** Public and enterprise APIs must be governed by an API constitution defining:\ 4.1.1 endpoint families and permitted use;\ 4.1.2 rate limits and safe load controls;\ 4.1.3 authentication and authorization requirements;\ 4.1.4 logging and audit trail minima;\ 4.1.5 backward compatibility and deprecation policy; and\ 4.1.6 schema versioning and interoperability commitments. 4.2 **Endpoint families (minimum).** Where implemented, endpoint families should include:\ 4.2.1 **Assets and scope** (domains, endpoints, dependencies, ownership claims);\ 4.2.2 **Observations** (headers, certificates, DNS, performance measurements, public signals);\ 4.2.3 **Findings** (vulnerabilities, misconfigurations, integrity signals, accessibility findings);\ 4.2.4 **Benchmarks and scoring** (method version, score outputs, confidence);\ 4.2.5 **Evidence artifacts** (AEP retrieval, lineage pointers, correction metadata);\ 4.2.6 **Alerts and bulletins** (severity, scope, uncertainty); and\ 4.2.7 **Governance metadata** (handling class, reliance bounds, version/supersession links). 4.3 **Audit logging.** APIs must produce logs sufficient to reconstruct:\ 4.3.1 who accessed which artifact and when;\ 4.3.2 which method versions produced which results;\ 4.3.3 changes to scopes, configurations, and policies; and\ 4.3.4 which outputs were superseded or corrected. *** #### 5. Alerting, Evidence Delivery, and Decision-Support Packaging 5.1 **Evidence-first alerting.** Alerts must be designed to route users from:\ **alert → evidence → context → decision record template**. 5.2 **Mandatory alert fields (minimum).** Alerts must include:\ 5.2.1 scope and affected assets;\ 5.2.2 observation vs inference distinction;\ 5.2.3 severity and rationale;\ 5.2.4 uncertainty/confidence indicators;\ 5.2.5 handling class and reliance bounds;\ 5.2.6 reproduction hints where safe; and\ 5.2.7 pointers to an AEP (where available) and correction path. 5.3 **Assurance & Evidence Pack linkage.** For consequential use cases, alerts should link to an AEP containing:\ 5.3.1 provenance chain;\ 5.3.2 method and version identifiers;\ 5.3.3 tests executed and their outputs;\ 5.3.4 limitations and known failure modes;\ 5.3.5 dispute and correction metadata; and\ 5.3.6 distribution log posture (where required by handling). 5.4 **Decision record templates.** The Platform may supply decision record templates that:\ 5.4.1 capture adopter authority and accountable decision maker;\ 5.4.2 record the scope, time window, and handling class;\ 5.4.3 reference the AEP(s) used;\ 5.4.4 record dissent/uncertainty and reliance bounds; and\ 5.4.5 link to correction/supersession updates. *** #### 6. Data Handling, Tenant Isolation, and Sovereignty Posture 6.1 **Tenant isolation.** The Platform must implement tenant isolation such that:\ 6.1.1 customer scopes, data, and evidence artifacts are logically and access-controlled;\ 6.1.2 cross-tenant access is prohibited by default;\ 6.1.3 administrative access is logged and governed; and\ 6.1.4 exported artifacts are explicitly labeled and traceable. 6.2 **Minimization doctrine.**\ 6.2.1 Collect and retain the minimum required to produce declared outputs.\ 6.2.2 Default to metadata, public endpoints, and consented telemetry rather than content capture.\ 6.2.3 Avoid PII and sensitive data by default; where unavoidable, apply strict redaction and handling. 6.3 **Retention and deletion.** Each deployment must define:\ 6.3.1 retention periods by artifact class;\ 6.3.2 deletion procedures;\ 6.3.3 legal hold posture; and\ 6.3.4 rules for de-identified or aggregated retention for longitudinal studies. 6.4 **Sovereignty considerations.** Where deployments are subject to data residency or sovereign constraints:\ 6.4.1 storage and processing location must be explicit;\ 6.4.2 cross-border transfers must be controlled and documented; and\ 6.4.3 portable, content-addressed evidence artifacts may be used to share proof without exporting sensitive source data. *** #### 7. Service Levels, Measurement SLIs, and Disclosure Discipline 7.1 **SLOs as disclosed commitments.** Service levels may be published, but must be framed as:\ 7.1.1 **availability and latency targets** for platform services;\ 7.1.2 **freshness targets** for monitoring pipelines; and\ 7.1.3 **correction commitments** for high-impact errors—without implying certification or guaranteed outcomes. 7.2 **Measurement SLIs.** Where offered, measurement SLIs must disclose:\ 7.2.1 sampling cadence and coverage;\ 7.2.2 known blind spots;\ 7.2.3 drift posture; and\ 7.2.4 variance expectations under real web conditions. 7.3 **Transparency minima.** Enterprise users must have access to:\ 7.3.1 method versions;\ 7.3.2 scoring rules (at least at a reproducibility-supporting level);\ 7.3.3 uncertainty indicators; and\ 7.3.4 correction and supersession notices. *** #### 8. Configuration, Change Control, and Safe Defaults 8.1 **Safe defaults.** Deployments must default to conservative collection, safe rate limits, and rights-preserving measurement. 8.2 **Change control.** Changes to: scope, measurement intensity, artifact retention, and disclosure posture must be:\ 8.2.1 recorded;\ 8.2.2 versioned;\ 8.2.3 auditable; and\ 8.2.4 reversible where feasible. 8.3 **High-risk configuration gates.** Any configuration that increases collection intensity or sensitivity must require:\ 8.3.1 explicit justification;\ 8.3.2 handling-class elevation; and\ 8.3.3 adopter authorization. *** #### 9. Boundary Notices and Mandatory Disclaimers for Enterprise Use 9.1 **Boundary notice (required).** All enterprise deployments and documentation must carry a clear boundary notice stating:\ 9.1.1 the Platform provides intelligence, evidence, benchmarks, and governance tooling;\ 9.1.2 the Platform does not execute, enforce, certify, or provide legal/compliance determinations; and\ 9.1.3 adopters remain responsible for decisions and actions. 9.2 **No implied endorsement.** Integration with enterprise systems must not be represented as: endorsement, certification, regulator approval, or a compliance guarantee. 9.3 **Non-procurement posture.** The Platform must not be used to publish “approved vendor” lists or procurement steering outputs. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.therisk.global/organization/cooperation/nexus-guilds/future-of-web/xii.-integration.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.