Scott Hardie

Senior Applied AI / Platform Engineer · Distributed Systems · Enterprise Architecture

Toronto, Canada · LinkedIn · Email

I build the systems around foundation models that make them safe to operate: policy-gated tool execution, tenant-isolated data, measurable inference cost, observable workflows, and evidence you can replay.

Target roles: Senior/Staff Applied AI Engineer · AI Platform Engineer · Distributed Systems Engineer · Solutions Architect

Interested in: teams shipping high-assurance AI, developer platforms, agent infrastructure, and enterprise-scale systems.

APPLIED AI · DISTRIBUTED SYSTEMS · MCP · POSTGRESQL RLS · eBPF SANDBOXING · FORMAL VERIFICATION

• I bridge architecture and implementation. I can align stakeholders on a system boundary, then build the Go, Rust, TypeScript, Python, database, and CI pieces that make the boundary real.
• I treat AI as a production systems problem. Models are useful; the surrounding controls determine whether a system is reliable, secure, affordable, and supportable.
• I make claims inspectable. My public work includes specifications, benchmarks, negative security tests, formal models, conformance vectors, and CI quality gates—not just screenshots or demos.
• I understand enterprise delivery. My work spans customer-facing architecture, identity and data integrations, institutional security, procurement conversations, and the operational constraints that decide whether a system ships.

If you are reviewing this profile for a role, these are the fastest paths to signal:

• Flagship portfolio — systems spanning ML infrastructure, AI governance, LLM FinOps, distributed execution, enterprise data, and formal methods.
• Architecture and technical writing — how I reason about production AI beyond model selection.
• Working stack — the languages, data systems, inference tooling, and infrastructure I use.
• About and contact — current role, enterprise background, and the best way to reach me.

Production AI needs deterministic boundaries around probabilistic components. The model proposes; typed policy services decide what may happen; execution systems perform only authorized work; evidence makes the result inspectable.

Intelligence can be probabilistic. Infrastructure cannot.

• Evidence over confidence: if a run cannot be inspected or replayed, it is not production-ready.
• Determinism at the edges: keep probabilistic behavior inside explicit schemas, policies, state machines, and execution limits.
• Security in the kernel: enforce tenant isolation and authorization where a missed application check cannot bypass them.
• Boring reliability wins: idempotency, retries, observable queues, and clear failure paths beat hidden cleverness.
• Cost is a correctness constraint: runaway inference spend is an operational failure, not merely a finance problem.

These four repositories are the most representative public evidence of how I work. The table is generated from a versioned manifest, checked against GitHub weekly, and separates released, beta, and research work.

Public project metadata last verified 2026-11-06 · source manifest · verification policy

Project	Problem	Public evidence
TokenGoblin · Go Measure · beta	LLM workloads need cost, usage, and routing data before teams can control inference spend.	Public ingestion benchmarks, cost and routing tests, and a repository-level CI workflow. Architecture · Evidence
ReadyLayer · TypeScript Govern · beta	AI-assisted delivery needs policy, review, and evidence before generated changes reach production.	Public policy contracts, evidence export documentation, test suites, and CI quality gates. Architecture · Evidence
veridag · Rust Prove · research	Distributed execution needs explicit ordering, capability security, and cross-language conformance.	A public protocol specification, Quint formal models, test vectors, and dedicated conformance workflows. Architecture · Evidence
Settler · TypeScript Reconcile · stable	Payment, banking, and operational records diverge unless matching and evidence rules are explicit.	Multi-tenant reconciliation engine v1.8.0, 20+ CI gates, public benchmark suite, and cryptographically verified release artifacts. Architecture · Evidence

I publish architecture notes that are grounded in the systems above:

1. Building Safe Multi-Tenant AI Agents with Postgres RLS — why application-level filtering fails in autonomous workflows, and how to enforce tenant boundaries in PostgreSQL.
2. Enterprise Tool Calling: Why Authorization Belongs Outside the Model — policy-gated MCP reverse proxies, unprivileged planners, and single-use approval tokens.
3. From Prototype to Production: Architecture for Enterprise AI Agents — model abstraction, execution boundaries, CI evaluations, observability, and token-spend governance.
4. Hardonia Architecture Playbook — system topology, bounded contexts, operating loops, and evidence verification.

git clone https://github.com/Hardonian/Hardonian.git
cd Hardonian
uv run python -m unittest discover tests -v
uv run python scripts/profile-metadata.py --check --verify-remote
uv run python scripts/profile-link-audit.py

I am a Solutions Architect at McGraw Hill and build Hardonia independently from Toronto. My work combines enterprise architecture and hands-on systems implementation: customer-facing technical strategy, distributed control planes, formal models, production TypeScript applications, and PostgreSQL isolation.

I also contribute part-time expertise to confidential frontier-AI evaluation and systems initiatives; client, model, dataset, and internal research details remain private.

Selected background:

• Enterprise integrations across identity providers, message buses, LMS/SIS/ERP platforms, and legacy data exchanges.
• Working knowledge of LTI 1.3 Advantage, OneRoster 1.2, OAuth 2.0, Keycloak OIDC, SCIM, MCP, and OpenTelemetry trace propagation.
• Institutional security and compliance conversations, including FERPA and SOC 2 requirements.
• President's Award for Sales Excellence, reflecting the ability to turn difficult technical work into customer and business outcomes.

Hiring managers and recruiting teams: the best way to reach me is LinkedIn or email. I am especially interested in roles where I can help turn ambitious AI capabilities into reliable platform primitives and shipped products.

If you are evaluating the engineering work first, start with TokenGoblin, ReadyLayer, veridag, or Settler, then follow the architecture links in each project.