AI Governance

Privacy and Anonymity

What COMPAiSS collects - and what it deliberately does not.

COMPAiSS is designed from the ground up to collect as little as possible. Every interaction is stateless - meaning nothing is stored once the system delivers a response. There are no user accounts, no session histories, and no connection between one query and the next.

Aggregated, anonymized usage patterns - for example, which topic areas generate the most questions - can be made available to the institution for service planning. These reports contain no individual-level data and cannot be traced back to any person.

Data Residency

Where your data lives - and where it does not.

For Canadian institutions, data residency is a legal and governance requirement, not a preference. COMPAiSS is built to meet that requirement directly.

The system does not connect to an institution's internal databases, records management platforms, or case management systems. It operates as an independent, secure layer - delivering verified, policy-aligned responses without touching internal infrastructure.

Security

How COMPAiSS handles the threats that IT teams ask about most.

COMPAiSS uses standard web security practices and is protected by Cloudflare's infrastructure. The following protections are active by default.

This result is not a configuration setting - it is a property of the architecture. The gate runs first. The AI only runs if the gate passes the query.

Access and Authentication

Open by default, controlled by choice.

COMPAiSS is currently delivered as a web-embedded tool - accessible to anyone with the link, on any device including smartphones, tablets, laptops, and desktops. No login is required and no software needs to be installed.

This open-access model is intentional for public-facing deployments. For example, prospective students researching programs, citizens seeking service information, or patients looking for guidance can interact directly with the institution's AI assistant without barriers - receiving accurate, source-verified answers drawn exclusively from that institution's approved content.

• Single Sign-On (SSO) SSO integration using standard protocols compatible with Microsoft Azure Active Directory can be scoped as a defined implementation item for any institutional deployment. This allows access to be restricted to authenticated users, and different content to be surfaced to different user groups - for example, staff versus public-facing access.
• Microsoft Teams Teams integration - allowing users to interact with COMPAiSS directly inside Teams without navigating to a separate page - is available as a scoped development item. If an institution identifies this as a priority, it can be defined and costed as part of the licensing agreement.
• Role-Based Access Different user groups can be shown different versions of the assistant with access to different approved content - for example, giving staff or clinical teams access to internal policy documents that are not surfaced in the public-facing deployment.

SSO and Teams integration are development options that can be built into a pilot from the outset - not features that require separate procurement or a new platform.

AI Model and Updates

Which AI powers COMPAiSS, and how model decisions are made.

COMPAiSS is model-agnostic by design, but currently - and deliberately - relies on a closed model. The governance architecture - the rules, the gate, the approved source list - sits entirely outside the AI model. This means institutions are never dependent on any single provider.

COMPAiSS currently uses GPT-5.2-latest by OpenAI as its AI engine. This model was selected based on direct comparative testing against available alternatives. It consistently performs best across the metrics that matter most for regulated institutional deployments: accuracy, helpfulness, tone, and the reliability of source links in responses.

The "latest" designation means OpenAI continuously improves this model in the background. An institution's COMPAiSS deployment benefits from those improvements automatically - with no updates, no downtime, and no action required.

High-Risk Situations

Why architectural non-engagement is the most important safety property of COMPAiSS.

The most significant safety question for any institution deploying AI in public-facing contexts is not whether the system can detect risk - it is whether the system can be drawn into a sustained, harmful engagement in the first place. Recent events in Canada make this distinction urgent.

COMPAiSS is structurally incapable of replicating this failure. The reason is architectural, not policy-based.

• Non-engagement as primary protection A query about planning violence does not match any institution's approved source list. The governance gate rejects it before the AI runs. The system returns a standard out-of-scope response and stops. No engagement, no rapport, no sustained relationship - by architecture, not by moderation policy.
• The gate cannot be bypassed by persistence Unlike a general-purpose AI that can be prompted, reframed, or manipulated into engagement over time, the COMPAiSS gate is deterministic. Out-of-scope queries are rejected on the first attempt and every subsequent attempt. There is no relationship to build because there is no engagement to sustain.
• Personal crisis queries are handled separately When a user's query contains language associated with personal distress or suicidal ideation, the system returns a pre-approved institutional response directing the user to the appropriate support resources - counselling services, campus security, or emergency contacts - as configured by the institution in alignment with its own duty-of-care policies.
• Institutional governance options How institutions configure crisis response protocols - including what triggers a response, what support resources are surfaced, and how the system handles repeated crisis queries - is a governance conversation COMPAiSS has with each institution during deployment. Different institutions have different policy obligations, and COMPAiSS is designed to support those differences rather than impose a single model.

The replication of a Tumbler Ridge scenario is architecturally impossible in COMPAiSS. Not because the system detects violence better - but because the system structurally cannot become the sustained planning tool that general-purpose AI can become. That protection does not depend on policy, moderation, or human review. It is a property of the gate.

Keeping Information Current

How policy and content changes flow through to user answers.

COMPAiSS does not store a fixed copy of institutional information. It retrieves content from a controlled list of approved sources at the time of each query - meaning updates to institutional pages flow through to user answers automatically, with no retraining, no waiting period, and no lag.

• URL-based updates are automatic If a policy page is updated but the web address stays the same, COMPAiSS picks up the change on the next query - no action required.
• New pages are added to the approved list on request If a web address changes or a new source needs to be added, COMPAiSS updates the approved list immediately. The change takes effect on the next query.
• The institution controls the approved list The institution retains full authority to add, remove, or update sources at any time. COMPAiSS cannot access any page that is not on the approved list.

This is a significant advantage over AI tools trained on static snapshots of information - those systems require expensive retraining cycles that can take weeks or months to reflect policy changes.

Greenlist Integrity and Maintenance

How COMPAiSS keeps its approved source list authoritative and current.

The greenlist - the institution-specific list of approved URLs that defines the epistemic boundary of each COMPAiSS deployment - is not a static configuration file. It is a living governance asset that requires regular verification to remain authoritative.

COMPAiSS includes a purpose-built audit server that checks every URL in an institution's greenlist against the live web, classifying each entry as confirmed active, redirected, broken, or unreachable. Audits can be run per institution or across all deployments simultaneously. Results are returned as structured JSON, enabling systematic triage and targeted remediation.

• Broken URL detection URLs returning 404 or DNS errors are identified and removed, ensuring the system never attempts to authorize queries against pages that no longer exist.
• Redirect classification Redirected URLs are categorized by type - permanent infrastructure redirects that are safe to retain versus content restructuring redirects that reflect renamed or moved pages. The latter are updated to their canonical destinations.
• Canonical URL normalization Where institutions have migrated to canonical domain structures, greenlist entries are updated to reflect the authoritative address - eliminating redirect hops and ensuring the greenlist matches what the institution itself designates as the correct URL.
• GitHub-integrated deployment Greenlist updates are committed directly to the institution's deployment repository. Railway auto-deploys on commit, meaning a corrected greenlist is live within minutes of the patch being applied - with no downtime and a full version history preserved in Git.

Greenlist audits are conducted on a regular maintenance cycle and whenever institutional web infrastructure changes are known to have occurred - for example, following a website redesign or unit restructuring. The audit result is the authority: URLs confirmed active are retained, and URLs confirmed dead are removed or replaced with verified successors.

Common Governance Questions

The questions procurement officers, legal counsel, and IT teams ask most often.

• What happens when a source URL goes down mid-query? COMPAiSS fetches content at query time. If a source is unreachable, the system draws from other authorized sources that did respond, or returns a safe failure response. It cannot fabricate content from a source it cannot reach - which is a governance advantage over RAG systems that cache retrieved content and can serve stale material without flagging it.
• How does this interact with our existing Acceptable Use Policy? COMPAiSS enforces a stricter epistemic boundary than most institutional AUPs require. Because the system only responds to queries within institution-approved scope, and because all responses are traceable to specific authorized sources, COMPAiSS is compatible with standard AUP frameworks by design. For institutions with AI-specific AUP provisions, the execution-gated architecture provides a documented, auditable compliance path that generation-first systems cannot match.
• Who is liable if the answer is wrong? COMPAiSS answers only from sources the institution itself has designated as authoritative. If those sources contain an error, the institution's liability exposure is no greater than if a staff member read from the same page. More importantly, COMPAiSS eliminates the category of fabricated institutional guidance - where an AI invents policy that does not exist - that creates the most serious liability exposure for institutions deploying generation-first AI. That class of error is architecturally impossible in COMPAiSS.

Institutional Accountability

What COMPAiSS means for governance, audit, and procurement review.

Regulated institutions do not only need AI systems that perform well. They need AI systems they can document, defend, and submit for formal review. Procurement officers, legal counsel, and governance panels increasingly require institutions to demonstrate not just that an AI system produces good outputs, but that its governance architecture is auditable, bounded, and aligned with the institution's obligations.

COMPAiSS is designed with that requirement in mind. Because authorization decisions happen before inference, every interaction follows a documented, reproducible governance path. The institution controls which sources are authoritative. The institution defines the scope boundary. The system enforces both by architecture - not by probability, not by policy alone.

For institutional evaluation, procurement, or governance review inquiries: [email protected]

Real-Time Governance Transparency

Live tools that make governance visible, not just documented.

COMPAiSS includes three real-time governance tools available to institutional administrators and authorized staff during deployment. These tools do not require external software, log downloads, or AI assistance to operate. Live examples of the Governance Delta in action, drawn from five active institutional deployments, are available on the COMPAiSS Demos and Pricing page. Each demonstration shows a real governed response paired with the ungoverned output the same AI model produces without the COMPAiSS execution gate, making the governance difference directly visible.