Safety & Compliance

Not just a claim — a stack. This page documents the elect-rix safety architecture, regulatory alignment, and governance. Built for procurement due diligence.

🇨🇦

Canadian Sovereignty

Data stays in Canada. Infrastructure Canadian-hosted or client-controlled.

🛡️

Security-First Design

Zero telemetry by default. Need-to-know access. Air-gappable.

📋

Procurement-Ready

PSPC, CCCS, and SR&ED documentation. Open to audit.

1. Data Sovereignty & Residency

For government and regulated clients, data sovereignty is non-negotiable. We treat it as architecture, not policy.

Canadian Infrastructure by Default

  • Primary lab physically located in New Brunswick, Canada.
  • All client data processed and stored in Canada unless explicitly requested otherwise.
  • Cloud deployments use Canadian regions only (Cloudflare CDN nodes, not compute).

No Foreign Data Dependencies

  • No US-managed cloud services for Protected workloads.
  • No third-party analytics, tracking, or telemetry services with foreign data processing.
  • For protected/client workloads, AI inference is local or client-controlled by default; client data is not sent to foreign AI APIs unless explicitly requested and approved in writing.

Client-Controlled Environments

  • Work product delivered to client-controlled infrastructure wherever possible.
  • Repository access granted to client — elect-rix does not hold sole keys.
  • On-premise deployment supported for air-gapped or sensitive environments.

2. Security Architecture

Security is layered — not a single tool. Every layer is inspectable and verifiable.

Layer 1: Physical Security

  • Dedicated hardware in a private, access-controlled space.
  • No co-location facilities or shared data centers.
  • Hardware owned, not leased or cloud-borrowed.

Layer 2: Network Security

  • Local-only development. No remote access to build machines.
  • Firewall rules default-deny. Only required ports open.
  • VPN required for any remote administration (site-to-site, not public endpoint).

Layer 3: Application Security

  • Static site output (Astro + Bun) — no server-side attack surface at runtime.
  • Dependencies are lockfile-controlled through bun.lock; dependency review and audit artifacts can be provided where required.
  • No third-party JavaScript trackers, analytics, or external scripts.
  • Zero runtime telemetry by design: ordinary content pages do not load third-party analytics, trackers, or external scripts.

Layer 4: Supply Chain Security

  • Builds are lockfile-controlled and static output can be reproduced from source for review.
  • Git commit hash = deployment identifier. One-to-one traceability.
  • All build tools open-source and verifiable (Astro, Bun, Tailwind).
  • Relevant to SBOM (Software Bill of Materials) requirements.

Layer 5: Human Security

  • One named principal with full accountability. No shell entities, no hidden subcontractors.
  • Need-to-know basis for all client data.
  • NDA and confidentiality binding on all personnel.

3. Cybersecurity Posture

Aligned with Canadian Centre for Cyber Security (CCCS) guidance and emerging procurement requirements.

ITSG-33 / ITSG-37 Alignment

  • Designed to map to Canadian government security baselines where applicable; formal control mapping can be produced per engagement.
  • Access control (AC), audit (AU), system integrity (SI) controls documented.
  • Security categorization available for Protected B workloads upon request.

Incident Response Preparedness

  • Defined incident response plan: detect → contain → eradicate → recover → document.
  • Client notification within 24 hours of any suspected data breach.
  • RCMP and CCCS reporting channels documented for applicable incidents.

Continuous Monitoring

  • Local system logs retained for forensic analysis.
  • Repository history is maintained in Git with author, timestamp, and deployment traceability; signed commits can be used for engagements requiring stronger provenance.
  • Each build can be traced back to source history and deployment records.

4. Access Control & Identity

Authentication

  • Two-factor authentication (2FA) enforced on administrative and third-party service accounts wherever supported.
  • No shared credentials. Individual accounts only.
  • Password managers used for secure credential storage.

Authorization

  • Role-based access control (RBAC) for client environments.
  • Need-to-know: only individuals directly working on a project have access.
  • Subcontractors (if any) provisioned with least-privilege, time-bounded accounts.

Lifecycle Management

  • Access automatically revoked upon project completion or termination.
  • Credential rotation on any suspected compromise.
  • No standing admin access to client production systems.

5. Privacy & Data Handling

Privacy is not compliance — it's a first principle. We design systems that collect nothing by default.

PIPEDA / FOIPOP Alignment

  • Data minimization: collect only what is required for the project.
  • Purpose limitation: data used only for the stated purpose, not analytics or AI training.
  • Consent basis: explicit, documented consent before any personal data processing.
  • Access and correction: clients can request all data elect-rix holds; corrections made promptly.

No Telemetry Architecture

  • Public elect-rix pages do not load third-party analytics or behavioral tracking scripts.
  • No Google Analytics, no Meta Pixel, no Hotjar, no Mixpanel.
  • No elect-rix analytics cookies are set; Cloudflare is used for public-site delivery, caching, and baseline edge protection.
  • This is verifiable: inspect the network tab on ordinary content pages — no third-party font, analytics, or tracking scripts are loaded by the site.

Public Site Verification Notes

  • elect-rix.tech is served as a static site; there is no application server handling visitor form data on ordinary content pages.
  • No client-side scripts are loaded by this page.
  • No analytics, advertising pixels, or behavior-tracking tools are installed.
  • No analytics cookies are set by elect-rix.
  • Cloudflare is used for public-site delivery, caching, TLS, and baseline edge protection only; edge-level operational logging is not used as elect-rix marketing analytics.

Data Retention & Destruction

  • Client data retained only for duration of engagement.
  • Post-project: return all artifacts or destroy per written instruction.
  • No retained copies in personal drives, email, or unsecured storage.
  • Certificates of destruction available upon request.

6. Regulatory Compliance

elect-rix.tech is structured to align with Canadian federal and provincial regulatory frameworks.

Regulation / Framework Alignment
PIPEDA Privacy-by-design. Data minimization. No telemetry. Consent-driven.
FOIPOP (NB / NS / PEI / NL) Government record handling. Access controls. Destruction protocols.
ITSG-33 / ITSG-37 Security control baselines. Risk assessment. Audit trail.
CCCS Cyber Guidance Supply chain integrity. SBOM readiness. Incident response.
WCAG 2.1 AA Accessibility targeted for all public-facing deliverables.
Canada's SR&ED Program R&D documentation. Eligible expenses tracked. Contemporaneous records.

Disclaimer: elect-rix operates as a trade name / brand of RixBot Technologies Inc., a New Brunswick incorporated company. While elect-rix aligns its practices with these frameworks, it is not a certified auditor or law firm. For formal certification requirements, certified third parties can be engaged on your behalf.

7. Government Procurement Readiness

Public-sector procurement demands proof, not promises. Here is how elect-rix is built to meet that bar.

PSPC / Shared Services Canada Readiness

  • Data residency in Canada by default — aligned with Protected workload expectations.
  • Personnel accountability: one named Canadian principal, no hidden subcontractors.
  • Reliability status and background check available upon request for sensitive engagements.

Small Business / Canadian-Controlled Supplier

  • May qualify for SME-focused procurement streams where program rules apply.
  • Streamlined procurement: direct engagement, no complex subcontractor tiers.
  • Regional-benefit documentation can be provided where relevant.

Documentation & Audit Trail

  • Deliverables can be maintained with version-controlled provenance in Git; signed provenance can be added where required by the engagement.
  • Full project documentation available for audit: requirements, design, test results.
  • Financial records maintained for SR&ED and tax compliance.

8. Fall Wall Inspection Framework

Fall Wall Inspection (FWI) is our internal safety verification methodology — a systematic check of the barriers that keep systems safe. When a wall falls, what catches it?

1. The Five Walls

  • Perimeter: network boundaries, firewalls, VPNs.
  • Identity: authentication, authorization, access lifecycle.
  • Data: encryption at rest, in transit, and in use.
  • Application: secure coding, dependency scanning, runtime integrity.
  • Human: training, policy, incident response, accountability.

2. Inspection Protocol

  • Each wall is tested independently: what happens when it fails?
  • Cascading failure analysis: does one wall's failure compromise the next?
  • Red team: simulate breach scenarios and measure response.
  • Blue team: verify detection, containment, and recovery capabilities.

3. Documentation & Attestation

  • FWI results documented per engagement, available to client.
  • Remediation items tracked to closure before go-live.
  • Re-inspection triggered by: new threats, infrastructure changes, or incidents.

FWI was developed by elect-rix.tech to address a gap in procurement: buyers need proof of safety, not just assurance. It is my answer to "how do we know it's secure?"

9. SR&ED & Innovation Tax Credits

elect-rix.tech actively tracks research and development activity for Canadian tax credit programs.

Eligible R&D Activities

  • Local AI inference optimization (new algorithms, quantization, hardware tuning).
  • Resilient system architecture (offline-first, air-gappable design patterns).
  • Privacy-preserving computation (zero-telemetry architectures, federated learning).
  • Reproducible build practices and supply chain tooling.

Contemporaneous Documentation

  • Lab notebooks in Git: dated, versioned, and attributable; signing can be applied where required.
  • Time tracking for all eligible R&D hours by project.
  • Expense records for qualified materials, equipment, and subcontractor costs.

Tax Credit Structure

  • SR&ED eligibility and credit treatment depend on claimant structure, expenditures, and CRA/provincial rules.
  • elect-rix maintains contemporaneous R&D records to support potential SR&ED claims where applicable.
  • Formal tax-credit positions should be confirmed with qualified accounting or tax counsel before filing.

10. Vendor Due Diligence Checklist

Use this checklist to evaluate any vendor, including elect-rix.tech, for government or regulated procurement.

  • ☐ Data Residency: Where is data created, processed, and stored?
  • ☐ Supply Chain: Can the vendor provide SBOM or dependency inventory?
  • ☐ Personnel Vetting: Named responsible party? Background checks available?
  • ☐ Incident Response: Defined plan? Client notification SLA?
  • ☐ Insurance: E&O / cyber liability coverage? Adequate for contract value?
  • ☐ Accessibility: WCAG compliance claimed? Verified?
  • ☐ Audit Trail: Version control? Signed commits? Deployment logs?
  • ☐ Indigenous / Regional Benefits: IRB eligible? Local hiring?
  • ☐ Termination: Data return / destruction? Certificate of destruction?
  • ☐ Subcontractors: Named? Bound by equivalent confidentiality?

Procurement Questions?

For SR&ED, government contract readiness, or due diligence documentation:

contact@elect-rix.tech

elect-rix.tech — Integrity. Loyalty. Honesty. — Tested.