The comprehensive operating plan

The manual and the LinkedIn About section both name competitions that are closed or that QHPC cannot enter. Fix these first — the whole calendar hangs off them.

The manual states QHPC's operating budget is "entirely dependent on the Dean's Donation Fund." In the 2026 cycle that fund moved from twice-yearly to once-yearly and dropped from funding roughly 80% of requests to 30–50%.

• Budget the Dean's Fund at roughly 40% of your ask. Nothing load-bearing should depend on the full amount.
• The application deadline is mid-November (2025–26 cycle: Monday 17 November, 8:00 a.m.), with a preparation workshop in early October. It requires an application package, budget template, academic advisor approval, and "a sponsorship package if available."

Every one of them has three things: an artifact, subteams with named leads, and an external deadline. QHPC has the third only in aspiration.

What QHPC already has that most of these needed years to build

• A working 5-node Raspberry Pi cluster — PXE/TFTP netboot, NFS scratch, passwordless SSH.
• Production Frontenac access through the CAC, with a written access guide.
• A complete curriculum already on disk — eight tutorial decks, five workshop scripts, a mock-SCC format.
• A speaker pipeline that landed NVIDIA/LLNL (Ian Karlin) and Sandia (Brooke Henderson).
• A faculty advisor (Ryan Grant) and graduate mentor (Curtis Shorts) who produce content for you.
• A Next.js site already scaffolded, publicly on GitHub.

Run this the way you'd design any growing organisation: a small executive layer with clear portfolios, a director layer under each exec who can be a first- or second-year hire, and a general membership organised into tracks. Violet marks seats aimed squarely at Commerce, Economics, or non-technical students — QHPC has real work for them, and naming it explicitly is what gets them to apply.

That's five exec seats, thirteen director/coordinator seats, plus the competition-team leadership and advisory board — twenty-odd named positions for a club that had three last year. You do not need to fill every seat in year one. Post the whole chart, fill the seats marked new first, and let the rest grow into it over two years — this is explicitly the multi-year structure, not a September-1 requirement.

Every seat below is postable on Breezy as its own listing. Where a seat is new this year, it says so.

RACI for the five processes that actually break a club

Every one of these has failed silently at some student org because "everyone thought someone else had it." Name the Accountable person for each before September.

Bus-factor backups

Every seat needs a named person who could run it for two weeks without notice. This table is the succession plan referenced in the risk register, §24 and §32.

Today every member gets the same Wednesday meeting, which serves neither the beginner nor the person ready to compete.

Borrow Hyperloop's December deadline

New members sample freely through the fall and commit to a Sprint track by early December — this also matches the grad-mentor plan's own Winter Week 1 milestone ("form S3 teams"). Add a First-Year Representative seat paired with mentorship, because first-years who join in September are still here for SC29.

Recruit outside ECE

aQuatonomous went 0 → 80 in one year recruiting every discipline. Ask Irina Pavich for the ECE-wide email and approach the equivalent advisors in Physics, Math & Stats, and Computing — HPC touches every one of them, per §14.

• Exec hiring runs through EngSoc's Breezy portal with the Director of Human Resources (hr@engsoc.queensu.ca). Interview panel of at least three required. Post against the full role directory in §05, not last year's three titles.
• The People Operations Coordinator owns this process so it isn't the President's fourth job.
• General member intake is a form, not a DM — one link at club fairs, feeding the newsletter and a skills question that routes people into Foundations, a Sprint, or straight to Research.
• Onboarding week one: Discord invite, repo/Drive access, Frontenac account request started (it takes time), Rocky Linux VM workshop.
• Contact Brandon at the CAC about the team's own server — this is in last year's grad-mentor plan and appears not to have been actioned. Get it spun up so returning members have access in week one; this may be separate from general Frontenac access.
• Credential handover is a named task: audit Login_info_and_passwords in April, confirm the incoming exec has GitHub org, email, and site/DNS access.

A proven five-stage process, lifted from Queen's Hyperloop

Hyperloop publishes its full recruitment process. It's fair, accommodating, and battle-tested on 100+ members a year — adopt it rather than improvising:

1. Application form — applicants pick the branch and subteam(s) they want. Critically, Hyperloop states plainly: "you do not need experience to apply", and resumes are collected only as tiebreakers and as interview material, not as a screen.
2. Interviews — roughly 15 minutes, 5–6 questions, conducted by three or more executives connected to the role. Typically within a week of the deadline.
3. Second-round interviews — only triggered when there are too many strong applicants to separate, avoiding arbitrary tiebreaks.
4. Offers & acceptances — candidates may be deferred or referred to a different position rather than simply rejected. On acceptance, an information form captures preferences, and the member immediately joins internal comms and the PD program.
5. Onboarding — branch-specific training beyond the general onboarding, plus introduction to the alumni network and corporate partners.

Two details worth stealing verbatim: referring a strong applicant sideways instead of rejecting them (it keeps good people in the funnel), and giving new members access to the alumni network on day one rather than treating it as a senior-member perk.

The 2023–25 team wrote down an explicit strategy and set of team-environment tenets in Obsidian canvases still sitting in the repo. They're good. Keep them rather than reinvent a code of conduct from scratch.

The objective hierarchy

Top-level goal: "Achieve the best outcomes for all team members — put every member in the best position to excel in HPC, measured by members getting hired or creating their own work." That outcome is built on two pillars: Make Us Known (reputation → industry connections → sponsorship) and Excel in Cluster Competitions (which depends on Form the Best Team, Develop Technical Skills, and Develop Management Skills). All of it rests on four enablers: Have the Best Training, Communicate Professionally, Be Great Financial Stewards, and Maintain the Best Team Environment.

The team environment tenets

How the team actually operates

• Only meet to solve problems collaboratively — no status-update meetings, no "show and tell" that could be a message instead.
• Meeting agendas go out 2–4 days ahead so people arrive with real ideas, not off-the-cuff ones. Templates already exist in the repo.
• Prioritise by due date first, penalty-for-lateness as the tiebreaker.
• Keep every task and file in one shared place — Queen's is a Microsoft shop, so MS Teams and Office apps are the path of least resistance, not a new tool stack.
• Optimise for both fast response time and high-bandwidth communication — match the channel to the message (quick Slack/Teams ping vs. a proper written doc).

Anatomy of the SCC application

Team description · diversity and recruitment context · hardware/software specification · institutional support · preparation plan · educational goals — plus a named advisor. Ask Ryan Grant or Curtis Shorts in September.

This is the mechanism the 2025–26 grad mentors designed, explicitly to prepare "for the 2026–27 season" — this year. Don't replace it; run it properly.

• A Sprint is a 4-week learning block ending in a lessons-learned presentation.
• Senior members set the topic in the weeks prior and lead each team through it.
• Members choose the application side (what it's used for, how it derives parallelism, build-system lessons, scaling graphs and analysis) or the systems side (concept overview, scripts/tests run, graphs and analysis) — and can switch or specialise sprint to sprint.
• Teams learn from documentation, research papers, and textbooks, and are expected to document heavily for future sprints. If nothing runs, that's fine — the learning is the deliverable.
• Four sprints a year: two in fall, two in winter, each feeding the next term's mock competition and, eventually, the real one.

Adapted directly from the 2025–26 grad-mentor plan, extended with this year's real deadlines. Map week numbers onto the registrar's published term dates once confirmed; Queen's fall term runs ~12 teaching weeks plus a reading week, which is exactly this template's shape.

Fall term

Winter term

Every Sprint and pod write-up is a publication candidate. Two posts a term is enough to look serious. Host it on your own site rather than renting a Medium.

The CUCAI pathway

Become a Student Club Partner; a designated team lead submits the project description and member list; those members are auto-approved against registration. Registration ran 15–25 January, confirmed by 30 January, for the 7–8 March conference at the University of Toronto campus. Tickets via Zeffy. Enquiries to chair@cucai.ca.

What a CUCAI paper actually looks like — measured, not guessed

All 37 papers in the CUCAI 2025 proceedings were indexed and three were downloaded and text-extracted to establish the real bar. The full index with direct PDF links is a separate deliverable; the findings that change QHPC's strategy are below.

CUCAI 2026 is drifting toward computational work — good news for QHPC

Both the 2025 (37 papers) and 2026 (35 papers) proceedings were indexed in full. The shift between them matters:

The standout is "Spectral features for Neural-initialized-Newton Solvers in Cardiovascular CFD simulations" — straightforwardly computational science, and the single most QHPC-adjacent paper in either year. Read it as a template; it is roughly what Research topic 21 (CFD with OpenFOAM) would produce. Meanwhile "Beyond Bill C-27: From AI Legislative Gaps to a Reformed AI and Data Act" is a pure law-and-policy paper, and B.A.I.L.I.F.F. is a legal-fairness framework — two more no-code entries confirming the §33 argument.

Net read: the conference is moving toward QHPC's territory, and systems work is still under-represented enough to stand out rather than blend in.

None of these need to be novel science. A well-run benchmarking study, a careful replication, or an honest scaling analysis is a legitimate undergraduate research output — the kind CUCAI, SCC applications, and department posters actually want. Each is tagged with a difficulty and a realistic output format. The Director of Research (§05) assigns these into Sprints and pods.

Start with Section 0 — the entry tier (E1–E12). Those twelve need no prior HPC experience and are what every new member should be routed through first. Sections I–VII are the intermediate core catalogue. Section VIII (36–47) covers frontier topics drawn from current 2025–26 HPC research. Section IX (48–53) maps directly onto verified Queen's research facilities that already need compute — the fastest route to faculty partnerships and the letters competition applications require.

I · Systems & performance — the most natural fit, runs directly on your own hardware

II · Parallel programming & applications

III · AI/ML systems — the QMIND-adjacent lane

IV · Domain applications — built for cross-department partnership

V · Systems security & reliability — defensive framing only

VI · Visualisation & HCI

VII · Sustainability & policy — the meta-research lane

0 · Entry tier — genuinely first-sprint topics No experience needed

The 53 topics that follow skew intermediate-to-hard. These twelve are deliberately different: a first- or second-year student with no HPC background can complete any of them in a four-week sprint, and each still produces a real chart, a real finding, and a real write-up. Assign these first. Nobody's first sprint should be a GPU port.

0b · Entry-tier build projects No experience needed

Buildable artifacts rather than studies, at the same accessibility level. Each is a resume line and something to demo at a club fair.

The first five things a new member should do

A concrete on-ramp, in order. Roughly the first month.

1. Set up the VM and log into the Pi cluster. The workshop doc already exists.
2. Submit one Slurm job that prints the hostname. Understand that it ran somewhere else.
3. Run E1 — time the same job on laptop, Pi cluster, and Frontenac. Make one plot.
4. Run E12 — the three MPI programs. Now you understand distributed computing.
5. Pick an entry topic and join a sprint team. You are now doing research.

VIII · Frontier topics — grounded in current HPC research

Topics 36–47 come from active 2025–26 research directions rather than textbook exercises. They are harder, but they put QHPC on genuinely current ground — and several are under-explored enough that competent undergraduate work is publishable.

IX · Queen's-specific topics — where local research already needs compute

These are grounded in verified Queen's research facilities. Each has a real department behind it, real software already in use, and a real reason to want QHPC's help.

Research topics produce write-ups; these produce artifacts members can point to, demo at club fairs, and put on a resume.

Pi Cluster v2 — the technical spec, in enough detail to actually build

The standing benchmark suite

One suite, run after every hardware or software change, feeding both competition prep and the Research Branch:

• HPL and HPCG — the two benchmarks every SCC scores on directly.
• HPL-MxP — the mixed-precision benchmark (low-precision LU factorisation with FP64 GMRES iterative refinement). Increasingly the one that separates serious teams, and effectively unrun at student level. Feeds topic 36.
• STREAM — memory bandwidth, cheap to run, useful baseline for topic 01.
• OSU Micro-Benchmarks — MPI latency and bandwidth, feeds topics 04 and 47.
• IOR and mdtest — parallel I/O throughput and metadata rates; feeds topic 43.
• One real application rotated termly from §14 Section II (LAMMPS, GROMACS, or OpenFOAM) — this is what separates a club that runs synthetic benchmarks from one that can credibly claim application experience on an SCC application.

This is the single highest-leverage idea in this document. Every other Queen's design team needs simulation or compute at some point — CFD, path-planning, battery modelling, trajectory simulation — and right now each one solves that problem alone, badly, or not at all. QHPC already has the cluster, the Frontenac access, and the HPC literacy none of them have. Position QHPC as the shared compute backend for the entire design-team ecosystem, the way QMIND positions itself as the AI backend for real companies.

A · Design-team clients — the compute-as-a-service program

The pitch to each captain is simple: "Stop finding your own compute. We already have the cluster and the Slurm literacy — bring us the simulation, we'll run it and teach your members to run it themselves." Every engagement becomes a joint Sprint, a shared write-up, cross-recruiting in both directions, and a natural joint-sponsorship conversation (a sponsor funding "shared design-team compute infrastructure" is a much bigger, easier pitch than funding one club's Pi cluster).

B · The first-year course client program — copy aQuatonomous exactly

aQuatonomous served as the client for APSC 103, the first-year engineering design course — first-years get assigned aQuatonomous's real engineering problem as coursework, months before they'd ever apply to join. Do the same thing. Pitch QHPC as a client for an APSC 100/103 project: "design and image a small compute cluster," or "benchmark and explain a 5-node Pi cluster." It's a genuinely good sophomore-level systems problem, and it puts QHPC in front of every first-year engineer before recruitment season even starts.

B2 · The national compute offer — to the whole CUCAI network

Following directly from the finding above. Six clubs across five universities publish annually into a conference where nobody has a cluster. The pitch to each is one sentence, and it is credible because it's true:

Each engagement produces a joint write-up, cross-recruiting, and a co-authored CUCAI submission — and it positions QHPC as infrastructure to a national community rather than one more club competing for attention within it.

B3 · Four named people to contact, and what they said

Full-text analysis surfaced the specific researchers who described hitting a compute ceiling. These are warm technical leads, not cold outreach.

C · Sponsor-adjacent consulting

• HPC onboarding workshops for sponsors' new hires — a differentiated sponsorship perk no other design team offers.
• Benchmarking-as-a-service for QMIND's inQUbate-incubated startups — a low-effort, high-goodwill favour that opens a QMIND collaboration.

D · The sovereign supercomputer — the single biggest positioning move available

Queen's is now building a $900M+ national supercomputing facility in Kingston with Bell Canada, explicitly framed around housing "Canada's largest cohort of researchers and students advancing extreme-scale systems." That claim needs a real student pipeline behind it to be true — and right now, QHPC is the only organisation on campus positioned to be that pipeline.

• Position QHPC explicitly as the undergraduate talent pipeline for the new facility. Every Foundations cohort graduate, every Sprint participant, every Research Branch contributor is a data point for "Queen's already trains extreme-scale-systems talent at the undergraduate level" — a claim the university's own PR now has reason to want to be true.
• Ask the CAC directly whether QHPC can be named a formal student stakeholder in the facility's planning — even an informal advisory or "voice of undergraduate researchers" seat is disproportionately valuable this early, before the structure solidifies.
• Approach Bell Canada as a sponsor with a specific, non-generic ask tied to this project — not "please support our club," but "you're already building supercomputing infrastructure in this city; help us train the students who'll eventually want to work in it." That is a fundamentally different, much stronger pitch than a cold sponsorship ask.
• Watch for workforce-development or internship language as the project matures through 2026–27 — MOUs like this routinely spawn co-op, internship, or training-program announcements within a year or two, and QHPC should be first in line when they do.

Verified, currently-existing units worth a first email this year. Where a specific staff contact isn't named here, that's deliberate — confirm the right person through the department's general office rather than guessing.

CUCAI lists its partner student clubs publicly. This is, in effect, a pre-assembled national network of undergraduate technical organisations that already travel to each other's events — and it is exactly the invite list for the regional and national rungs of the conference ladder in §22.

The most likely 2026–27 reality: Frontenac access secured and free, Dean's Fund cut to ~40% of ask, zero sponsors. That position is stronger than it looks — and it should drive every decision below.

The core principle: spend compute, not capital

Prefer work whose only expensive inputs are CPU-hours, GPU-hours, and student time — all of which QHPC already has for free. Apply this filter to every proposed project:

• Needs new hardware purchased, a paid licence, travel, proprietary data, or physical fabrication → defer.
• Needs lots of compute, open software, and open data → do it now.

The key move: reframe the Pi cluster

The instinct is to spend scarce money scaling the Pi cluster from 5 to 10 nodes. Resist that. Split the roles explicitly instead:

Under this split the Pi cluster does not need to grow to be valuable. It's the teaching instrument, the club-fair demo, and the photo in the sponsorship deck. If in-kind hardware arrives, grow it; if not, the research programme is unaffected. That decoupling is what makes a zero-budget year survivable.

The entire HPC stack is open source

Rocky Linux, Slurm, OpenMPI, OpenMP, Apptainer, Warewulf, Prometheus/Grafana, OpenFOAM, LAMMPS, GROMACS, HPL, HPCG, STREAM, OSU Micro-Benchmarks, PyTorch, ParaView — all free. Writing runs on Overleaf's free tier with the IEEE template, and CUCAI's own bound proceedings is LaTeX-generated with hyperref, so matching their toolchain costs nothing either. The one real exception is Ansys and SOLIDWORKS, which are commercial — and both already give in-kind licences to Queen's Hyperloop, so ask rather than buy.

How the research catalogue re-scores under a zero budget

Ten topics immediately free, nine more free with a partner, three blocked — and one of those three unblocks with a single equipment ask. A zero-budget year costs QHPC almost nothing in research capacity.

What a $0 year actually costs

Foundations curriculum, four sprints, eight research topics, both competition entries, four published write-ups, the mock competition, weekly meetings, guest speakers, Discord and newsletter: all $0. The only unavoidable expense in the entire core programme is a domain name, roughly $15–20 a year.

And it makes the sponsorship pitch stronger, not weaker

Being capital-light means every dollar is visibly marginal rather than keeping the lights on: "Our research runs on infrastructure we already have and software that's free. We're not asking you to fund our existence — we're asking you to remove three specific constraints we can't engineer around: measurement equipment for the energy study, GPU hardware for the teaching cluster, and cloud credits for the competition that runs on provided cloud resources." Named, bounded asks against named, blocked work convert far better than a general appeal.

• Account 2722 at the Bank of EngSoc. Finance training arrives at the club email at the end of summer.
• Preliminary budget early, using past budgets as reference. Any later change needs the Director of Finance to re-approve.
• Use the EngSoc credit card, not reimbursements — ask Jay Young in the EngSoc lounge.
• Anything reimbursable must be in the approved budget first. Keep every receipt, file it to SharePoint.
• Update the actuals column after every event.

Income model

The ask sequence

1. Warm campus first — ECE, CAC, Smith Engineering, and now Bell Canada via the sovereign-supercomputer MOU, §16D.
2. Warm industry second — Ian Karlin (NVIDIA), Brooke Henderson (Sandia), three weeks after their talk, asking for something small and specific.
3. Kingston/Ontario hardware vendors third — in-kind, specific asks convert better than generic ones.
4. Cold corporate last, only with a real package behind it.

What a Queen's design team's sponsorship ladder actually looks like — with real numbers

Queen's Hyperloop publishes its full tier structure with dollar thresholds. This is the single most useful sponsorship benchmark available, because it's a peer team on the same campus, under the same EngSoc rules, asking the same donors.

Three lessons QHPC should copy immediately:

• Name the tiers after something thematic, not Gold/Silver/Bronze. "MACH IV / III / II / I" is memorable, on-brand, and costs nothing. QHPC's equivalent writes itself — PETAFLOP / TERAFLOP / GIGAFLOP / MEGAFLOP, or node counts, or EXASCALE at the top.
• Queen's Sci '62 and Sci '44 are alumni class gifts. Graduating-class funds are a real, recurring, campus-internal funding source sitting at the top two tiers of Hyperloop's ladder — bigger than most corporate sponsors. Almost nobody thinks to ask. Route this through Queen's alumni relations and the DEI/Alumni committee, §28.
• Food sponsors are free and trivially winnable. Insomnia Cookies, Chatime, Tahini's, Subway, and A&W all sponsor a Queen's design team in-kind. That covers the entire socials line in the §37 budget for the cost of five emails.

A researched target list — not a generic corporate wishlist

Every name below has a specific, real reason it fits QHPC, pulled from this year's actual research — not a copy-pasted list of big logos.

• Website first — the scaffold exists; add content, buy the domain.
• Set the domain to auto-renew, and put the renewal date in the transition manual. This is not boilerplate — see the warning immediately below.
• Newsletter is the real funnel — aQuatonomous and QMIND both run one.
• A template set beats better tools — one layout each for speaker announcements, recaps, and recruitment.

Tiers and target lists are inputs. This is the actual operating procedure — sequence, timing, scripts, and what to say when they push back.

The ask calendar

The three-touch sequence — never more

1. Touch 1 — the specific ask. Name the exact item, the exact use, and the Queen's precedent. Offer a tier. Under 200 words.
2. Touch 2 — day 10. Two sentences. Add one new piece of information (a result, a photo, a competition acceptance), not just "following up."
3. Touch 3 — day 21. "Closing the loop — is this something you'd revisit next cycle?" This converts a no into a later, and gets you a date.

Then stop, and log it. The single most valuable artifact you leave the 2027–28 exec is a record of who said no and why.

Objection handling

Sponsor fulfilment — the part clubs forget

Securing a sponsor is half the work; keeping them is the half that determines whether next year's exec inherits a relationship or starts cold.

• Within 48 hours: thank-you email, logo placement confirmed, named contact for the year.
• Mid-year: a short update with a photo and one concrete result. Unprompted. This is what makes renewal easy.
• Year-end: a one-page report — what their contribution enabled, in specifics. "Your licence supported three research projects and two publications" beats "thanks for your support."
• Always: Smith Engineering acknowledgement on materials is a standing Dean's Fund condition. Bake it into the poster template rather than remembering each time.

The Dean's Donation Fund treats clubs and design teams differently and requires academic advisor approval specifically for design teams. QHPC's actual work — a cluster, an international competition, a faculty advisor — is design-team work. Have this conversation with the Director of Clubs and Conferences this year; the compute-utility positioning in §16 makes the case for you.

This plan covers one year. But several of its highest-value moves — a vendor partnership, design-team status, a hosted event — only pay off across multiple cycles. Here is what each year should be for, so that no single exec team feels obliged to do everything.

"Recruit more members" is not a plan either. This models the funnel explicitly so the Education and Comms leads know what to optimise, and what a healthy conversion rate looks like.

Where funnels actually leak, and the fix

This plan is the strategy. Twelve companion documents carry the execution detail. Nothing here is intended to be read cover to cover — the point is that when a director needs a specific thing, it exists.

Routing table — which document answers which question

The failure mode of a document set this size is that nobody knows which one to open. Route by the question, not by the title.

• The QHPC Transition Manual 2025–26 (provided directly).
• The club's own 2025-2026_teams_files repository: the 2023–25 org-chart drawio and canvas files, the "Organizing a High-Performance Team" and "QSCCT Strategy" strategy canvases, and the grad mentors' "QHPC Planning 2025–26" deck — the direct source for the Sprint Model and the week-by-week calendar in §10–11.
• A live LinkedIn benchmark of QMIND, Queen's Relectric, Smith Hyperloop, QADT, aQuatonomous, and CUCAI, read directly in July 2026.
• Public pages for the Centre for Advanced Computing, Smith Engineering's research centres, and Queen's School of Computing's research groups, used to build the partnership list in §17.
• Public competition pages for ISC, SC/SCC, SCC Connect, Winter Classic, and CUCAI.
• The Queen's Gazette, SFU News, Bell's own newsroom, and Datacenter Dynamics coverage of the January–March 2026 Bell/Queen's/SFU sovereign AI supercomputing MOU.
• Live pages for cucai.ca and qmind.ca, including sponsor logos and alt text read directly from each site, used to build the researched sponsorship target list in §19 and the partnership additions in §17.
• Public pages for the Digital Research Alliance of Canada (Explora) and the Dunin-Deshpande Queen's Innovation Centre.

ISC 2027 and SC27 dates are extrapolated from published 2026 cycles and must be confirmed before anything is planned around them. Where a specific staff contact wasn't already named in QHPC's own materials, this plan deliberately points to a department or office rather than a guessed individual. Instagram accounts could not be read programmatically in this research pass; the peer-channel benchmark in §20 is LinkedIn-only.

A topic list is not a plan. These five are written as runbooks a second-year member can execute without further guidance — software, data, method, deliverable, and the failure modes that actually bite.

Runbook 1 — HPL/HPCG benchmarking across configurations $0

Runbook 2 — Strong vs weak scaling of an open scientific code $0

Runbook 3 — Slurm scheduling policy comparison $0

Runbook 4 — GPU offload study $0 on Frontenac Hard

Runbook 5 — Survey of undergraduate HPC education in Canada $0 No code

The complete materials list for the Research Branch. Note how little of it costs money.

Frontenac — the verified node inventory

Pulled from the CAC's own hardware wiki, not the marketing summary. This is what QHPC actually has access to, and it changes several planning assumptions.

Frontenac — environment facts every runbook depends on

Sprints produce presentations. Papers need a further four weeks. This is the conversion process, and without it the Research Branch generates slide decks that die on a shared drive.

"Train for the competition" is not a plan. These are the specific skills scored, and how to drill each.

Three-person clubs don't need governance. A twenty-seat organisation running consulting engagements, handling sponsor money, and touching other people's research data does. This doesn't need to be heavy — it needs to exist and be written down.

The Board of Advisors — distinct from the exec

The exec (§04) runs the year. The Board exists so the year isn't the only thing anyone is thinking about. Meets once a term, thirty minutes, no operational decisions — only direction, conflict resolution, and continuity.

The one-page charter

Adopt this formally at the first exec meeting of the year — it's the constitution the objective hierarchy in §08 deserves, made procedural:

1. Purpose: the top-level objective from §08, verbatim.
2. Decision rights: the President breaks ties; each VP has final say within their own portfolio; anything touching money above a threshold (set it — e.g. $200) needs two exec signatures.
3. Removal process: the culture doc already says persistent dishonesty or contempt for teammates is cause for removal — the charter specifies how: a Board majority vote, with the affected person given a chance to respond first.
4. Amendment process: the strategy is "provisional, not dogma" (§08) — formalise that as a simple majority exec vote to change any part of this plan, logged in the transition manual with the reason.
5. Conflict of interest: any exec with a personal or financial stake in a sponsorship or consulting decision recuses from that vote.

A twenty-seat org chart creates silos by design. Committees are the deliberate seams that stop that from happening — each pulls two or three directors from different VP lines, meets monthly, and reports to the President.

Five committees, each meeting monthly, each with a one-page written output — this is a small enough overhead that it does not need its own hires; every seat on it is already a director elsewhere in §05.

The moment §16 becomes real — QHPC running compute for Hyperloop, or for a department — someone has to answer "who owns the results, and what happens if it goes wrong." This is exactly the kind of problem a Law student finds genuinely interesting, and it's a real, resume-worthy project for one.

A lightweight engagement template — draft this with a Law-student volunteer, then have EngSoc or Queen's Legal Counsel review it before first use

• Scope of work — one paragraph: what QHPC will run, for whom, by when.
• Data and IP ownership — the client (design team or department) owns their design data by default; QHPC retains the right to publish the general methodology and benchmark numbers with the client's sign-off, never their proprietary design details without permission.
• Compute allocation and responsible use — what resources, for how long, and what "done" looks like.
• Liability limitation — QHPC provides best-effort student work, not a warranted professional service; this needs to be explicit so nobody assumes competition-grade guarantees.
• Confidentiality — a short clause covering anything the client shares that isn't meant to be public.
• Sign-off — both team captains, plus the faculty advisor countersigning anything above a small effort threshold.

Two Research Branch topics (§14, topics 19 and the health-adjacent stretch in §17) touch genomics and medical data. Get the boundary right before anyone runs a real dataset.

• Default to public and open datasets for every Research Branch topic unless a named faculty co-supervisor has a formal data-sharing agreement in place.
• QHPC members never handle identifiable health data directly. Anything touching Kingston Health Sciences Centre or patient-level data is brokered entirely through the CAC and goes through Queen's Research Ethics Board — full stop, no exceptions, no matter how interesting the dataset is.
• A simple three-tier data classification — Public (no restriction), Internal (club use only, e.g. member survey data from §33), Restricted (requires named faculty sign-off, e.g. anything from a hospital, a company, or a government partner) — gives every Director a one-line answer to "can I use this."

• The 2023 team safety plan is already in the repo — update and re-sign it annually rather than starting from a blank page; it's what a design-team-status conversation (§21) will ask for anyway.
• Hardware work (soldering, wiring the Pi cluster, rack assembly) happens supervised, with basic PPE, never solo late at night.
• Off-campus activity — any competition travel, external workshop, or client site visit needs the EngSoc sanctioning form, confirmed with the VP Student Affairs ahead of time.
• Venue accessibility — confirm Dunning 10's wheelchair access and whether a hearing loop or captioning is available for guest talks; ask before someone has to.
• An emergency contact sheet for every in-person event, held by the Events Coordinator.

A plan this detailed is only as good as its worst-case branches. Ten scenarios, worked through in advance, so nobody is improvising during the actual crisis.

§04–05 covers the twenty-seat core that runs the year day to day. This is the extended bench — real, useful, resume-worthy roles that let a student from any faculty plug in without pretending to be an engineer. None of these require code.

Hard evidence for the postings — from the CUCAI corpus

Don't assert that non-technical students can contribute. Show them four papers, all by Queen's undergraduates, none containing a single line of code:

And the pattern underneath it: cross-referencing author lists across both years, Kate Sigurdson co-authored both the award-winning 2025 consciousness paper and the 2026 Bill C-27 paper; Kay Yan co-authored the 2025 music-copyright paper and authored a 2026 paper on bias auditing in financial AI. These students are building genuine multi-year publication records in AI policy without writing code. That's a career track, not a token gesture — and it's the single most persuasive thing you can put in front of a Law or Political Studies applicant.

Three different students should be able to look at this and each see themselves in year three.

Track A — the technical path

Track B — the research path

Track C — the business/ops path

• QHPC Fellows — any graduating member who completed a Sprint, a Research Branch topic, or an exec term gets a standing invitation back as a speaker, judge for the mock competition, or informal mentor.
• An annual "state of the cluster" letter to the Fellows list — five minutes to write, keeps alumni as a live network instead of a one-time thank-you.
• Office Hours — a termly, optional video call where a Fellow takes questions from current members. Ian Karlin and Brooke Henderson are the first two obvious invitees once they've spoken once.

Sprints, Research Branch topics, open-source contributions, and consulting engagements are all trackable units of work. Make that visible.

• A simple leaderboard (Discord bot or a shared sheet) tracking Sprints completed, topics published, and engagements delivered — not for competition's sake, but so quiet contributors get seen.
• End-of-term recognition at the social: a few named awards drawn directly from what actually happened that term (best write-up, most improved, best first-year contribution) rather than generic categories.
• Every completed Sprint or topic goes in the person's own portfolio, not just the club's — a one-line write-up they can paste into a resume or LinkedIn post, prepared by the Content & Publications director as a standard service.

Illustrative planning figures, not quotes — replace every number with a real one once vendors and the DDF outcome are known. The point is the shape of the budget, not the digits.

Note what's absent even at Stretch: no line for onsite SC/ISC travel or a vendor-hardware SCC entry — those depend on a vendor partnership (§19) that realistically doesn't exist until SC28. The Conservative column should be the one the club can run comfortably on with zero surprises.

None of these require the club to be a registered non-profit or design team — they're academic programs built for exactly this kind of use, and applying costs a form, not money.

• Asset inventory — every piece of cluster hardware gets a QR-coded tag and a named custodian, logged in a shared sheet. This is the direct fix for the "hardware walks" risk in §24/§32.
• Ask ECE or EngSoc for dedicated, lockable storage — even a single cabinet turns "who has the Pi cluster this week" into a solved problem.
• A backup/redundant parts kit — a spare SD card set and one spare Pi board means a single hardware failure never cancels a demo.
• Insurance — ask the EngSoc General Manager whether club equipment is covered under any existing property policy before assuming it is or isn't.

• E-waste — route retired hardware through Queen's existing surplus/e-waste channels rather than the trash; this is a five-minute email, not a program.
• Carbon accounting — Research topic 34 (§14) can literally be run on the club's own infrastructure choices, turning an internal decision into a public research output.
• Financial accessibility — no member should be blocked by cost. Waive any nominal fees on request, no questions asked, and check whether the Queen's library's laptop-lending program (if one exists) can cover members without a personal machine capable of running the VM setup workshop.
• Event accessibility — captioning or a transcript for recorded guest talks costs almost nothing and meaningfully widens who can benefit from the club's best content.

• One logo file, one colour palette, one type pairing — owned by the Visual Designer (§33), used by everyone else without re-deriving it each time.
• A tone-of-voice note: direct, specific, a little dry — closer to how this document is written than to exclamation-point marketing copy. Consistency here is what makes a growing club still feel like one organisation.
• Smith Engineering's logo placement is a standing requirement from the Dean's Fund, §02 — bake it into the template rather than adding it after the fact each time.

Three posts a week is sustainable indefinitely and gives new members something to see between Wednesdays; it's not a burden if it's this templated.

Short, low-production video or audio interviews with alumni, sponsors, and faculty partners — Ian Karlin and Brooke Henderson are the obvious first two guests. Produced by the Media Producer role in §33, hosted wherever the newsletter already lives. This doubles as sponsorship inventory (§19's Gold tier) and as durable recruiting content that outlives a single social post.

§08's objective hierarchy is the "why." This is the "by when," broken into the academic year's four natural quarters.

Beyond ISC, SC27, and SCC Connect (§09), one more is worth a research pass before next year's plan is written — this one is flagged as unverified, deliberately, rather than asserted as fact.

1. Watch isc-hpc.com from 1 August. It's the only competition entry available before March, and it's free to enter.
2. Post all twenty core seats, not three — Finance, Sponsorship, Consulting, Marketing, Content, Events, and DEI are real jobs for Commerce, Arts, and Law students who currently assume this club isn't for them.
3. Run the Sprint Model exactly as the grad mentors designed it — it already works, and it's already built to feed this year's competition prep.
4. Pitch one design team and one first-year course as compute clients this term — the single highest-leverage strategic move in this whole plan, and it only needs one warm conversation to start.
5. Budget as if the Dean's Fund gives you 40% of what you ask for, because the data says it will, and build the year so nothing breaks if it does.

# 1. generate draft data (synthetic only; skip on real data)
python scripts/synthetic_data.py --grid configs/grid.json --prompt-file configs/prompt.txt --out data/synthetic --seed 42

# 2. analyze (D1-D4, BH-FDR)
python scripts/analyze.py --pi-dir data/synthetic/pi --server-dir data/synthetic/server --out results/synthetic

# 3. figures + table1 (fig1_crossover, fig2_heatmap, fig3_joint, fig4_robustness, fig5_margin)
python scripts/plots.py --pi-dir data/synthetic/pi --server-dir data/synthetic/server \
    --cells results/synthetic/cells.csv --crossover results/synthetic/crossover.csv \
    --verdict results/synthetic/verdict.json --grid configs/grid.json --out figures/synthetic

# 4. manuscript table
python scripts/make_table1_tex.py figures/synthetic/table1.csv figures/table1.tex

# 5. tests (40 tests, 1 skipped)
python -m unittest discover -s tests

Imported from measurement-execution-plan.md (2026-08-08), derived from t-cpu2-measurement-execution-checklist.md. Phases A-G: pre-execution checks, grid definition, per-cell measurement protocol, pre-registered decision rules (D1-D4), robustness checks, slot-fill mapping, and the synthetic-first automated pipeline (40 tests, 1 skipped). Complements the Operating Plan above.

# 1. generate draft data (synthetic only; skip on real data)
python scripts/synthetic_data.py --grid configs/grid.json --prompt-file configs/prompt.txt --out data/synthetic --seed 42

# 2. analyze (D1-D4, BH-FDR) — real: --pi-dir data/pi --server-dir data/server
python scripts/analyze.py --pi-dir data/synthetic/pi --server-dir data/synthetic/server --out results/synthetic

# 3. figures + table1 (fig1_crossover, fig2_heatmap, fig3_joint, fig4_robustness, fig5_margin)
python scripts/plots.py --pi-dir data/synthetic/pi --server-dir data/synthetic/server \
    --cells results/synthetic/cells.csv --crossover results/synthetic/crossover.csv \
    --verdict results/synthetic/verdict.json --grid configs/grid.json --out figures/synthetic

# 4. manuscript table
python scripts/make_table1_tex.py figures/synthetic/table1.csv figures/table1.tex

# 5. tests (15/15 pass)
python -m unittest discover -s tests

Imported from t-cpu2-measurement-execution-checklist.md (2026-08-08). Source runbook for the Measurement Execution Plan above.