Selected work · Canopy

Mathieu Côtéat Canopy

Platform engineer at Canopy. I moved us onto our own infrastructure, hardened how we manage access, and I work on the data protection questions that come with handling Canadian health records.


Projects
07
Since
May 2026
Org
Canopy
Scroll
01

Platform Infrastructure2026Shipped

AWS Migration

Moved the entire platform off KNALYSIS and onto Canopy infrastructure.


RolePlatform engineer, working the migration with a four-person team

Problem

The platform was still running on KNALYSIS infrastructure that Canopy did not own or control. Every change depended on an external environment, and the longer the arrangement lasted the more the estate accumulated configuration nobody had authored and nobody could safely touch.

Approach

Mapped the running estate against what the product actually required, then moved workloads onto Canopy-owned AWS accounts in stages rather than as a single cutover. Working through it as a team meant the operational knowledge transferred with the systems instead of staying with the previous owner.

Outcome

Canopy now owns and controls its own infrastructure end to end, with primary data sitting in Canadian regions. That last part matters more than it sounds: you cannot make a residency commitment about infrastructure somebody else runs, so this is what made the compliance question answerable at all. The migration also surfaced the security and cleanup work that became the next phases of the project.

02

Security Engineering2026Shipped

Security Hardening

Brought the inherited estate under clear ownership and control.


RoleSecurity and platform engineer, audit through rotation

Problem

Infrastructure inherited through a migration carries whatever access patterns the previous owner happened to leave behind. Credentials had accumulated across services without a clear owner for each, and the estate still ran services the product no longer depended on. Every one of those is something that still has to be patched, monitored, and reasoned about at two in the morning when something breaks.

Approach

Audited what each credential actually reached before changing anything, so consolidation would not take down live systems. Rotated and reduced access down to a single clear owner per service, then worked through the inventory and decommissioned what was no longer in use. Reducing the estate was the point: the most reliable way to secure a service is not to be running it.

Outcome

Access is now scoped and attributable. Every credential has one owner and a known blast radius. The running estate is materially smaller than what the migration inherited, and the surface that has to be defended shrank with it.

03

Identity & Access2026Shipped

Multi-Factor Authentication

Three ways to prove who you are, so no clinic gets locked out.


RoleEngineer, authentication flows and enrolment

Problem

Access to a platform holding clinical data rested on a password alone. In healthcare that is the wrong place to stop. Passwords get reused across systems, shared between staff on a busy floor, and phished, and with a single factor any one of those is enough on its own.

Approach

Shipped three enrolment paths (authenticator app, SMS and email) rather than mandating one. Clinic staff work across shared workstations, personal phones and desk phones, and a single-method rollout would have locked out whichever group it did not fit. Offering all three meant MFA could be required without carving out exceptions that quietly become the norm.

Outcome

Every account is now protected by a second factor, and staff choose the method that matches how they actually work. A leaked password on its own is no longer enough to reach anything.

  • 3Enrolment methods
04

Accessibility & Compliance2026Shipped

French Localization

Quebec clinic staff work in the language they think in.


RoleEngineer, internationalization and translation delivery

Problem

The platform shipped in English only, while a significant share of clinic users and staff work primarily in French. In Quebec that is not just a usability gap, it is a regulatory expectation. It is also a safety one: asking clinical staff to work in a second language invites exactly the kind of misreading that healthcare software cannot afford.

Approach

Retrofitted internationalization across an interface that had been built assuming one language, which meant pulling hard-coded strings out of the components rather than simply adding a translation file. Prioritized the clinical and administrative paths staff use daily so the translation landed where comprehension actually carries risk.

Outcome

Staff work in French or English by preference. The platform meets Quebec language expectations, and the groundwork now exists to add further languages without repeating the retrofit.

  • 2Languages supported
05

Product Design Engineering2026Shipped

Interface Modernization

A calmer interface for people who stare at it all shift.


RoleFrontend engineer, design and implementation

Problem

Clinic staff live in this software for entire shifts, often on shared workstations in rooms where a bright screen is the wrong thing to have. Navigation took permanent space from the content people were actually there to read, and the interface had not kept pace with the platform behind it.

Approach

Added a dark theme built on proper contrast ratios rather than an inverted palette, so it holds up in dim clinical rooms without sacrificing legibility. Rebuilt the sidebar to be fluid, so it expands when someone is navigating and gets out of the way when they are working. That gives screen space back to the content, which matters on the smaller displays these workstations tend to have.

Outcome

The interface now suits the environment it is used in. Staff choose the theme that suits their room and their eyes, and the working area grew without anything being taken away.

06

Systems Integration2026In progress

Environmental Integration Layer

Staff learn one interface, however many systems we add behind it.


RoleEngineer, integration architecture, with Maintenance & Environmental Control

Problem

The estate runs horticulture controllers, HVAC and building systems over BACnet and Modbus, PLCs and SCADA, plus standalone sensor networks that answer to none of them. Each one arrives with its own interface, its own vocabulary, and its own idea of what a reading even is. Every system added to a site meant retraining the staff who operate it, and that cost lands on the same people every time the estate grows.

Approach

Building an abstraction layer that normalizes every system to one shared model, so the frontend speaks a single vocabulary no matter what sits underneath. This is a deliberate trade. It pushes the real complexity onto the development side, since every new vendor needs an adapter written against the common model, and that is the point: the complexity stops there instead of reaching the people operating the building. Designing it with the Maintenance and Environmental Control team is what keeps the model honest to how these systems behave in practice rather than how their documentation claims they do.

Outcome

In progress. The target is that adding a system becomes a development task rather than a training event, so Canopy staff learn the interface once and keep that knowledge as the estate expands.

07

Privacy & Regulatory2026In progress

Canadian Data & Health Compliance

Mapping what actually applies before anyone claims we comply with it.


RoleEngineer, gap analysis and the technical controls behind it

  • 4Regimes in scope
Problem

Four separate regimes land on the same systems here. PIPEDA covers personal information federally, Quebec Law 25 adds consent, breach reporting and rules about moving data out of the province, provincial health information law applies wherever we hold identifiable client health records, and the Cannabis Regulations impose their own record and retention obligations on top. They overlap in some places and pull in different directions in others, and none of it had been mapped against what we actually run. Compliance is not in place today. Saying that plainly is more useful than assuming it is.

Approach

Working through each regime against the real system inventory rather than against a generic checklist, because the only questions that matter are specific: what personal and health information do we hold, where does it physically sit, who can reach it, and how long do we keep it. The AWS migration put primary data in Canadian regions, which is the part that makes residency controllable at all, though some services still run in the US and Law 25 expects a transfer like that to be assessed rather than assumed. Where controls were obviously needed and obviously missing, they shipped ahead of the analysis: MFA on every account, credentials scoped to a single owner, and a service estate small enough to actually reason about.

Outcome

In progress, and deliberately framed as a gap register rather than a compliance claim: which obligations apply to which systems, what already satisfies them, and what does not. Law 25 expects a privacy impact assessment before new systems go live, so having this mapped now is what stops the next project inheriting the same unknowns.

Research & Development

What I think we should build next.

Forward proposals · not yet built

Ideas for Canopy

  • Quality AssuranceNear term

    SOP Studio

    Treat SOPs as structured, diffable documents instead of Word files on a drive.

    Right now an SOP is a .docx on SharePoint, which means the revision history is a filename, the review trail is an email thread, and the French version is a separate file that starts drifting the moment anyone edits the English. A binary blob cannot be diffed, so "what changed in rev 4" is a question nobody can answer quickly. Storing SOPs as structured content fixes all three at once: real diffs between revisions, review and approval state attached to the document itself, and the English and French versions linked as one record so editing one flags the other as stale instead of letting them quietly diverge.

    Where I'd start

    Model one existing SOP as structured content and prove the EN/FR link plus a clean revision diff before touching the wider library.

    • Diff any two revisions instead of guessing
    • Review and approval tracked on the document
    • French version can never silently fall behind
  • SecurityNear term

    Phishing-Resistant Admin Access

    Bind privileged access to hardware-backed credentials through Conditional Access.

    The MFA rollout raised the floor for every account, which was the right first move. It is worth being honest about what it does not cover though: TOTP codes can be relayed through a proxy in real time, and SMS is interceptable. Both are still shared secrets that a convincing login page can harvest. WebAuthn is a different category, because the credential is bound to the hardware and scoped to the origin, so a lookalike domain simply cannot use it. Since we already run Entra ID, this is a policy problem more than a build: Windows Hello for Business or FIDO2 keys enrolled for admins, then an authentication strength requirement on privileged roles so the weaker factors stop being accepted where they matter most.

    Where I'd start

    Enrol the admin group on FIDO2 or Windows Hello, then enforce a phishing-resistant authentication strength on privileged roles in Conditional Access.

    • Nothing on the admin path is phishable
    • Credential tied to the device and the origin
    • Attributable trail for every privileged action
  • Internal ToolingMid term

    In-House Planning Suite

    One planning tool where rooms, cycles and strains are real entities, not text labels.

    Every team currently plans in whatever tool they picked, so there is no shared view and no way to roll anything up. The deeper problem is that none of those tools know what a room or a cycle is. A task referencing "Room 4, week 3" as a string cannot be joined against anything, which is why a plan and the actual state of production drift apart within days and nobody notices until it matters. Building this in-house means planning items reference production entities by ID, so a schedule can be validated against what is really happening in the rooms and a delay in one cycle visibly moves everything downstream of it.

    Where I'd start

    Define the shared entity model first (rooms, cycles, strains, batches) and expose it as an API. The board is the easy part once that exists.

    • One view across teams instead of six tools
    • Plans reference real production entities
    • Our planning data stays on our infrastructure
  • Machine LearningMid term

    Light Control & Strain Modelling

    Reconcile fixture output with canopy sensors, then learn what each strain actually wants.

    Fixtures report lumens and wattage, but lumens are weighted to human eye sensitivity and undercount exactly the red and blue a plant uses, so fixture output on its own is a poor proxy for what reaches the canopy. PPFD sensors measure the real thing but only at the point they sit. The genuinely interesting engineering is reconciling those two into one trustworthy signal, then controlling on accumulated DLI across a cycle rather than on a fixed on/off schedule. That alone should cut energy and the hours spent adjusting light by hand. The modelling comes after: once there is instrumented history tying light delivered to how a strain actually performed, a model can start proposing setpoints per strain instead of everyone inheriting settings that were never revisited.

    Where I'd start

    Instrument first. Log fixture output alongside canopy PPFD for a full cycle, and get closed-loop DLI control working before any model is trained.

    • Lower energy draw and fewer manual adjustments
    • Per-strain setpoints grounded in measurement
    • More consistent yield across cycles
  • InfrastructureMid term

    Edge Infrastructure, Not More On-Site Servers

    Keep the control gateway local because it has to be. Move everything else to the edge.

    There is a real argument for on-site compute, and it applies to exactly one thing: the environmental control gateway talks to PLCs and controllers on the local network and has to keep running through a WAN outage. That box stays. The proposal to also put application servers and databases at each site does not follow from it, and I would push back on that. It multiplies the hardware, patching, backup and failure domains by the number of facilities, and it makes a local outage take down the application for that site instead of just its control loop. Serving the app from the edge means one deployment covers every region, and a Cloudflare Tunnel gives each site a secure outbound path to the control gateway with no inbound firewall exposure at all.

    Where I'd start

    Draw the honest line first: list what genuinely requires local presence versus what is on site out of habit. Move one non-critical service to the edge and measure it.

    • One deployment serves every region
    • Per-site hardware limited to the control gateway
    • A site outage stops taking the whole app down
  • PlatformLonger term

    Canopy Environmental Control

    Own the control logic, not just the integration layer sitting in front of it.

    Behind the integration layer there are horticulture controllers, HVAC and building systems over BACnet and Modbus, PLCs and SCADA, and standalone sensor networks that answer to none of them. The layer already normalizes all of that into one model, which means the last thing still owned by vendors is the control logic itself: setpoints, schedules, interlocks and alarms. Owning that is what stops a vendor roadmap from setting the ceiling on what a facility can do. It has to be approached carefully rather than quickly, because the hard realtime and safety interlocks belong close to the hardware and should stay there. The supervisory layer above them is the part worth building.

    Where I'd start

    Start supervisory and read-only. Own scheduling, alarming and setpoint orchestration above the vendor controllers before taking on anything safety critical.

    • Vendor roadmaps stop capping our capability
    • One consistent control model across every site
    • Full data access for everything downstream

Proposals · nothing here is in production yet