This is the plan for the new Job Board product (called the Job Bank in v0.1). v0.2 adds Mike’s review decisions to v0.1. The blueprint review on Fable comes next and uses this file as its input. The backlog is still AIDA_Job_Bank_Backlog_v0.1.csv, beside this file; a v0.2 backlog will add the new items listed in section 0.

0. What changed in v0.2

#	Change	Where
1	Renamed to AIDA Job Board. This keeps it clear of the federal Job Bank (jobbank.gc.ca). The subdomain becomes `job-board.aidalabs.ca`, the edition becomes `products/aida-jobboard/` with model `jobboard.yaml`, and the spin-up script becomes `new_jobboard.zsh`	1, 1.1, 3, 12
2	College demo approach decided (branded demo, demonstration bar, links out to their real pages, Prospect skin kit)	3.1
3	Job pool for self-hosted clients decided: a one-time snapshot comes with the one-and-done install, and a metered feed licence is available to offerings 2 and 3	4
4	Delivery through AIDA Git, our own self-hosted git server on Quebec, with an account for each client	4.1, 12
5	Collector expansion: career pages of consulting firms, and of large fitness, wellness and spa chains. Collectors are built per hiring platform, and employers are added as config rows	7.3
6	aidalabs.ca to be restructured around its real products, with the Job Board launched as one of them	14
7	Decision list split into decided and still open	15
8	Roadmap updated: the Diner is built first, AIDA Git stood up early and kept light, collector expansion with the first build, site restructure in R6	16
10	AIDA Mail (self-hosted mail on Quebec) added as a backlog item	4.2
9	All remaining open decisions settled: profiles accepted, approval rules as on/off options, English + French in every edition, Watch list wording, PWA first, snapshot included for offering 3	5, 10, 13, 14, 15

1. What the product is

The database and the data collectors behind the job sites become the product. The AI pieces (Airlock, Data Queen, scoring) become an optional add-on instead of the headline.

One core, many fronts:

Layer	What it is	Where it already lives
Job pool	Postgres `career_perfection` on the Toronto Mini: `job_postings`, `employer_feeds`, `posting_ats`, `employer_report_card`, blocked employers, closed checks	`career_perfection/migrations/001–076`
Collectors	Python collectors, switched on and off and scheduled in `collector_settings`, with run history in `collector_runs`	`client_dashboard/collectors.py`, `closed_checks.py`, `career_pages.py`, `ats_keywords.py`, `employer_cards.py`
Read-only API	Only the named `jobs_api.*` functions; everything else returns 404	`AIDA_Labs/db/jobs_data.sql`, `jobs_api` compose
Tenant portal	One PocketBase per client on Quebec, built from a metadata model (objects, record types, profiles, permission sets, scopes)	`AIDA_Labs/products/aida-portal/` (core.yaml, generate_model.py, skins, add-ons, new-portal scripts)
Analytics	Live Job Market Data	`jobs-data.aidalabs.ca`
Delivery	Project Board, Blueprint, portal pop-up, explainer videos, learn site, AIDA Git (new)	`projects.aidalabs.ca`, `blueprint.aidalabs.ca`, `videos.aidalabs.ca`, `learn.aidalabs.ca`, `git.aidalabs.ca`

Recommendation: build the Job Board as a new edition of AIDA Portal (products/aida-jobboard/), the same way Studio and Coach are built, with a new model package jobboard.yaml. The tenant’s own data (users, saved jobs, files, their own postings, translations) lives in the tenant’s PocketBase. The shared job pool stays in Toronto and is reached only through read-only jobs_api functions. This reuses the permission generator, permission tests, skins, new-portal scripts and publish pattern, so we don’t write a second platform.

1.1 Name: AIDA Job Board (decided)

“Job Bank” is the name of the Government of Canada’s job board (jobbank.gc.ca), and a college careers office would think of it first. Decision: the product is AIDA Job Board in all copy, file names and subdomains.

“Job board” is an everyday term, so the brand that can be protected is AIDA Job Board as a whole. Always use the full name in product copy.
We still have a collector named job_bank (migration 068) that reads the federal site. Rename its label in the admin screens to Job Bank Canada (federal) so it can’t be confused with anything of ours.
Rename plan and backlog files from AIDA_Job_Bank_* to AIDA_Job_Board_* from v0.2 on (v0.1 is kept as it is).

2. What we reuse (look here first)

Requirement	Existing component to copy and adjust	Gap
Accounts, sign-in, roles	aida-portal `users` object, profiles + permission sets, `test_permissions.py`	New profiles (section 5)
Search the database	`jobs_api.search` + facets (062), Search Jobs pop-up on portal.html	Wrapper scoped to the tenant, with the tenant’s own postings merged in
Save jobs	My Selected Jobs (portal.html)	Port to PocketBase `saved_jobs`
Resume / cover letter filing	Attached files feature, resumes table (043, 049, 050)	Port to tenant `documents`
Resume packages	aida-custom-resume kit formatting scripts (docx/pdf/txt), resume headline feature	Wizard front end (section 9)
Career search profiles, keyword layers	Profiles + keyword tuning (058, 064, 065), whole-word matching	End-user editor with live preview
ATS detection	`posting_ats.ats_system` + `ats_keywords.py` (063)	Roll-up by employer (section 8)
Employer report card	`employer_cards.py`, 075, blocked employers + public notes (073/074)	Rename cards, add treatment measures
Collectors on/off, no deletes	`collector_settings.enabled`, dry runs, `collector_runs`	Per-source on/off for each tenant; recipe format (section 7)
Closed / link checks	`closed_checks.py` (071)	Coverage of job boards and aggregators (section 8.2)
Admin panel	admin.aida-job-search.ca (client_dashboard)	New tenant admin built on the portal, not a copy of the staff dashboard
Project plan / blueprint / board	Project Plan data model v0.1, CTB blueprint, projects.aidalabs.ca	Install Package wrapper, sprint + kanban, comments (section 12)
Code and package delivery	None yet	AIDA Git on Quebec (section 4.1)
Explainers	aida-explainer-video skill, Video Library	Scripts per edition and per client
Apps	portal.aidalabs.ca already ships `manifest.json` + `sw.js`	Branded PWA for each tenant
Law 25 groundwork	Own certificates, self-hosted fonts, PII tokenization design (JS-01)	Checklist portal (section 11)

3. The three sites

Site	Audience	Brand	Purpose
aida-job-search.ca → the Job Search Diner	Job seekers, LinkedIn traffic	AIDAverse: the Diner, AIDA the Ultimate Hostess (new raven ponytail), links into the Drive-In and RMDb	Our own live Job Board and marketing funnel
job-board.aidalabs.ca	Buyers: colleges, settlement agencies, workforce boards	AIDA Labs Paris dusk, AIDA LABS menu and five site buttons	The professional product demo, with no AIDAverse jokes
College demo (first: Collège Boréal Toronto)	One prospect, by password	The prospect’s colours, with their logo used as a reference	Shows the Job Board as a turnkey fit for them

jobs.aidalabs.ca stays the phone/tablet trial copy. Its new AIDA image becomes the link to its explainer (section 14).

3.1 The college demo (decided)

We don’t clone a college’s pages into a look-alike site, and we don’t copy their pages, logo or photos into a dummy site that passes as theirs. A copy of a real institution’s site with a working sign-up page reads as impersonation as soon as the link is forwarded beyond the person it was meant for.

The demo is:

A page we build ourselves in their colours, with their logo used as a reference: their palette, type feel and layout rhythm, the Job Board fully working with live data, in French and English (Boréal is a francophone college).
A thin “Prepared for Collège Boréal by AIDA Labs · Demonstration” bar at the top of every page, so the page is safe to forward inside the college.
Links out to their real pages (Placement, Programs, Contact) instead of copies.
A one-minute explainer made for them, with the AIDA graphic linking to it, as on aidalabs.ca.
A “how it would sit on your site” picture: a framed mockup (a screenshot of their real Placement page with the Job Board panel drawn in), used inside the explainer and the proposal, not as a live page.
Password-protected at demo-boreal.aidalabs.ca (or a path on job-board.aidalabs.ca), behind the same sign-in protection as the other private sites, and noindex.

Prospect skin kit: enter the prospect’s name, colours, logo file and links to their real pages, and the new-portal scripts build a branded demo tenant with the demo bar and an explainer. That’s how each new college gets a fast spin-up.

4. Offerings

	1. Hosted re-skin (subscription)	2. One-and-done install	3. Standalone + maintenance licence
Who hosts	AIDA Labs (Quebec tenant)	Client’s server	Client’s server
Job pool	Live AIDA pool via `jobs_api`	One-time snapshot included; their own collectors after that; feed licence available	One-time snapshot included at install; their own collectors; feed licence available
Their own postings	Yes, visible to their users only	Yes	Yes
Upgrades	Automatic	None	Each new version, via AIDA Git releases
Support	Included	Install, test, hand-over, then none	Ticketed support at a fee
Install Package	Hosted by us	Delivered through AIDA Git, tagged release	Delivered through AIDA Git, kept current for upgrades

Each offering comes in two modes: Standalone (no AI at all: the Airlock add-on and every AI page are absent, not hidden) and Airlock Available (the jobs.aidalabs.ca AI features as an add-on, with PII tokenized before any AI step).

Job pool for self-hosted clients (decided)

Snapshot (included with offerings 2 and 3): a one-time copy of the current pool, taken on install day. It gets them running at once and gives them a few days to build and test whatever they like. Job postings go stale within about a week, so after that the snapshot is theirs to maintain with their own collectors, or they move to the feed.
- Contents: postings and employers only. Never profiles, scores, client data, resumes, or the scam and blocked-recruiter notes.
- Terms: for the client’s internal use only, no resale or republishing, and no feeding it into a competing job board.
- Delivery: an expiring download link from Quebec, not in the git repository (it’s large, it ages fast, and it’s the licensed asset).
Feed licence (offerings 2 and 3): a metered, read-only API key into jobs_api. This is the recurring line. Clients who try to keep their own collectors running usually find it’s cheaper to pay for the feed.
- Feed keys are issued, rotated and revoked by app admins only (section 5.3).

4.1 Delivery: AIDA Git (self-hosted git server)

The Install Package code and releases are delivered from our own git server, AIDA Git, at git.aidalabs.ca on the Quebec server.

Software: Forgejo (free and open source, a light single service, works with Docker), behind the same certificates and protections as the other Quebec sites.
One account per client, with read access to their own repository only. When a licence ends, the account is switched off (accounts are disabled, never deleted).
Releases: each version is a tagged release. One-and-done clients keep the release they bought. Maintenance-licence clients get each new release.
Stays in Canada: code, accounts and history stay on our Quebec server, which supports the Law 25 / data residency story (section 11).
Our own use too: AIDA Labs’ own code (portal kits, collectors, sites) gets a private home with history, which also counts as an off-Mini backup of the code.
Licence note: once a client has cloned a release, they keep that copy. The licence terms protect the code from then on, not the server.
App admin only: creating client accounts, repositories and release keys (section 5.3).
Timing (decided): stand it up early but light, in R0. It’s a small job: one Forgejo container, an nginx site and a certificate on Quebec, which are mostly commands you run. Our own code moves in first, so it backs up our code from day one. Client accounts, release packaging and snapshot links wait for the Install Package release. If setup starts using up time or tokens, it drops down the list without blocking anything else.

4.2 AIDA Mail (backlog: self-hosted mail on Quebec)

There’s no @aidalabs.ca mail today, so this is a clean start with nothing to migrate.

Phase 1, system mail: Job Board notifications, account approvals and portal emails sent from a subdomain (for example notify.aidalabs.ca). The Job Board needs this anyway.
Phase 2, mailboxes: real @aidalabs.ca mailboxes, run in parallel with existing addresses for a few weeks before anyone relies on them.
Software: Stalwart (light, about 1 GB of RAM) or Mailcow (full-featured, about 6 GB), chosen to fit the room left on the Quebec server.
OVHcloud specifics: outgoing port 25 is blocked by default and is opened through a support request; reverse DNS (PTR) is set in the OVHcloud Control Panel; SPF, DKIM and DMARC records are required. Until port 25 is open, mail can go out through a relay on port 587.
Ongoing care: spam filtering, updates and blocklist checks, plus mail included in the nightly backup.

5. User types, profiles and permissions

These follow the aida-portal pattern: each user has one profile (what they are), plus optional permission sets (extra rights). They are generated into PocketBase rules and proved by the permission tests.

5.1 Profiles

Profile	Who	In one line
`public`	Anyone not signed in	Search, see analytics, see a job’s public page; saving a job sends them to sign-up
`end_user`	Students, job seekers, newcomers	Their own account, saved jobs, files, resume builder, search profiles
`data_admin`	Careers office staff	Approve accounts, load jobs, manage translations and help text, run reports
`system_admin`	Client’s lead admin / AIDA ops	Turn users, workflows, sources and collectors on and off; add sources from recipes
`app_admin`	AIDA Labs engineers only (the “system gods”)	Anything that can cause permanent change

Recommended permission sets (added to a profile, never a profile of their own):

Permission set	Adds	Typical holder
`translator`	Edit translations for assigned languages only	Volunteer or staff translator
`job_poster`	Create/edit the tenant’s own postings, but not approve accounts	Employer-relations staff
`analytics`	Admin analytics pages and exports (anonymous figures only)	Managers
`collector_builder`	Create and test new source recipes in dry run; cannot switch them on	Client’s technical staff
`compliance_reviewer`	Comment on and sign off checklist items	Privacy officer
`airlock_user`	AI features (Airlock Available mode only)	End users who opt in

5.2 Permission matrix (recommended)

C = create, R = read, U = update, Off = enable/disable. No profile below app_admin can delete anything. End users can withdraw their own consent and ask for erasure; the erasure itself is carried out by an app admin script with a log (section 11).

Area	public	end_user	data_admin	system_admin	app_admin
Search jobs, job pages	R	R	R	R	R
Analytics (public view)	R	R	R	R	R
Own account and profile	–	RU	–	–	–
Saved jobs, files, resumes, search profiles	–	CRU own	R (support, logged)	–	R
Account requests	C (sign-up)	–	RU approve/refuse	RU	RU
Users	–	–	C invite end users, Off end users	C, Off any non-app-admin	everything
Tenant’s own job postings	–	R	CRU, Off	CRU, Off	everything
CSV / site job loads	–	–	C (validated, previewed)	C	everything
Translations, labels, help text	–	R	CRU, Off languages	R	everything
Data sources and collectors	–	–	R status	Off, C from recipe, U settings	C new source types, U code
Workflows (approval, notifications)	–	–	R	Off, U settings	C
Backups / restore / rollback	–	–	–	Request restore	Run
Schema, migrations, model changes	–	–	–	–	Run
Hard delete, privacy erasure, purge	–	Request own	–	–	Run (logged)
Secrets, API keys, Airlock on/off, feed licences, AIDA Git accounts	–	–	–	–	Run
Compliance checklist	–	–	R	RU comments	RU, sign-off

5.3 What only app admins can do (anything that can cause permanent damage)

Schema and model changes, migrations, new objects or fields.
Hard deletes of any kind, including privacy erasure, retention purges and removing a tenant.
Restores and rollbacks (system admins can request one).
Writing or changing collector code, and adding a new type of source (a new hiring-platform reader).
Secrets: API keys, SMTP, feed licences, Airlock and any AI provider key.
Turning the Airlock add-on on or off for a tenant (it changes what data leaves the system).
Changing backup schedules and retention.
Creating, upgrading or decommissioning a tenant or Install Package.
Editing the audit log (no one can; app admins can export it).
Changing permission rules themselves.
AIDA Git: creating client accounts and repositories, publishing releases, issuing snapshot links.

5.4 Account approval (decided: rules are on/off options)

The sign-up form creates an account request. Each approval rule is a separate switch in the tenant’s settings, turned on or off by a system admin:

Manual approval: a data admin approves from the admin panel or from the email.
Auto-approve by email domain: a list of domains (for example @collegeboreal.ca). Requests from other domains fall through to manual approval if it’s on.
Auto-approve all: every request approved at once, with a notification.

The switches combine (for example domain auto-approve plus manual for everyone else). If every switch is off, sign-up is closed and accounts come only by invitation or bulk import. The data admin gets an email and an admin-panel badge for every request either way. New tenants start with manual approval on and the others off.

6. Objects, record types and layouts

6.1 Objects (new `jobboard.yaml` package on top of core)

Object	Record types	Notes
`job_postings` (read-through view of the AIDA pool)	`pool`	Never stored in the tenant; fetched by `jobs_api`
`tenant_postings`	`employer_posting`, `co_op_placement`, `internal_campus_job`, `event`	The tenant’s own jobs, visible to its users only; merged into search
`saved_jobs`	`pool`, `tenant`	Status: saved, applied, interview, offer, closed (feeds `client_job_outcomes`)
`documents` (core)	`resume`, `cover_letter`, `generated_package`, `portfolio`, `reference_letter`	Version history kept, nothing overwritten
`resume_profiles`	`builder`, `uploaded`	One per user per resume; parent of the five objects below
`work_history`, `education`, `certifications`, `skills`, `achievements`	–	Child records of a resume profile
`contact_card`	–	Name, phone, email, city, links (portfolio, LinkedIn, GitHub); reused in every package
`search_profiles`	`simple`, `advanced`	Keyword layers and weights; simple = 3 boxes, advanced = layers
`keyword_layers`	`must_have`, `nice_to_have`, `exclude`, `title`, `location`	Weight 0–100
`account_requests`	`self_signup`, `invited`, `bulk_import`
`job_loads`	`single`, `csv`, `site`	Each load keeps its file, preview, row errors and who approved it
`data_sources`	`employer_feed`, `career_page`, `job_board`, `ingest_api`, `n8n_workflow`, `tenant_csv`	Never deleted: `enabled`, `disabled_reason`, version
`collector_recipes`	`ats_config`, `declarative`, `python`, `n8n`	Versioned; every change is a new version
`collector_runs` (mirror)	`dry_run`, `live`	Read-only summary for the tenant
`languages`	–	Code, name, enabled, completeness %
`translation_strings`	`label`, `instruction`, `help`, `email`, `error`, `page_text`	One row per key per language
`help_articles`	`end_user`, `data_admin`, `system_admin`, `app_admin`	Feeds learn.aidalabs.ca and in-app help
`compliance_items`	`law`, `requirement`, `control`, `evidence`	Section 11
`consents` (core)	`terms`, `privacy`, `marketing_email`, `airlock_ai`	CASL and Law 25 records
`privacy_requests`	`access`, `correction`, `erasure`, `portability`, `withdraw_consent`	Tracked to deadline
`notifications`, `audit_log` (core)

6.2 Layouts (one per profile; phones use dropdowns, per the standing rule)

Profile	Home layout	Record layouts
public	Search bar, three headline stats, featured employers, sign-up	Job page: title, employer, ATS used, posted, link to employer, Save (→ sign-in)
end_user	My Saved Jobs (status dropdown), My Documents, Build my resume, My Searches	Job: plus save status, notes, which resume I sent. Resume profile: wizard steps
data_admin	Queue: account requests, job load errors, translation gaps, help requests	Account request: approve / refuse with reason. Job load: preview grid with row errors
system_admin	Collector board (on/off, last run, rows, errors), users, workflows	Data source: settings, run history, dry-run button, enable/disable with reason
app_admin	Tenants, backups, migrations, audit export, feed licences, AIDA Git accounts	Everything, plus the destructive tools behind a typed confirmation

Field labels: every field gets a label_key (for example saved_jobs.status.label) instead of showing the field name, so labels can be translated from day one.

7. Data collectors

7.1 What exists

Python collectors in collectors.py: readers for Greenhouse, Lever, Ashby, SmartRecruiters, Workable and Workday, plus Job Bank Canada (federal) and career pages. On/off and schedule are in collector_settings, the run log is in collector_runs, and dry runs can be started from the page. The n8n workflows were retired one by one as Python matched them. That’s already the right shape: enable/disable, never delete.

7.2 Recommended formats (four levels, easiest first)

Level	Format	Who can add one	Example
1. Config row	One row: hiring platform + employer slug	System admin, in a form	`greenhouse` + `shopify`
2. Declarative recipe	JSON/YAML: URL, list selector or JSON path, field map, paging	`collector_builder`, tested in dry run	A college partner’s career page
3. Python plugin	One file with a standard `read(source) -> rows` function	App admin	A new hiring-platform reader
4. Ingest API / n8n	Any tool POSTs postings to `/ingest` with an API key; we ship ready n8n JSON templates that call it	Client’s tech team	n8n, Make, Zapier, a CSV export

Why this order: most new sources a college will want are employers on a hiring platform we already read, so level 1 covers most of them with no code. Level 4 answers the n8n question cleanly: rather than running clients’ n8n workflows inside our system, we give them n8n templates that post to one validated ingest endpoint. That way every source goes through the same checks (de-duplication, blocked employers, Canada filter, ATS read-out).

Rules for all levels: every source and recipe is versioned; switching one off keeps its data and history; a new recipe always runs a dry run first and a system admin switches it on; a bad version rolls back to the last good one in one click; the recipes and settings tables are backed up nightly.

7.3 Collector expansion in this build (decided)

Two new employer groups join the pool as part of this build:

Consulting firms’ career pages: the Big 4, the large strategy, technology and IT consultancies, and the Canadian mid-size firms, starting with firms that hire in Canada. The list then grows from what our clients actually target.
Large fitness, wellness and spa chains: national and regional gym, studio, wellness and spa chains. This is also the AIDA Coach and AIDA Studio market, so the data supports selling those too.

How we build it (design points accepted):

Collectors are built per hiring platform, not per company. Large employers mostly post through a handful of hiring systems. We already read six; the expansion adds readers (level 3) for the platforms these groups use that we don’t read yet. Likely candidates are iCIMS, SAP SuccessFactors, Oracle Taleo / Oracle Recruiting, and UKG or Dayforce for the retail-style fitness chains; the discovery step confirms which.
Each employer is then one config row (level 1). Adding 200 employers is an afternoon of rows, not 200 scrapers.
Discovery step first: for each employer on the list, find their careers page, detect the hiring platform (using the existing ats_keywords.py detection) and record it. Employers on a platform we can’t read yet wait for its reader; small one-off sites get a level 2 recipe.
Lists with limits: each group starts with a written list (name, careers URL, platform, Canada presence) that you approve. It grows deliberately rather than trying to cover “all” firms at once.
Existing rules still apply: Canada only by default, with US postings opt-in per client profile; blocked employers and scam / résumé-harvester tracking apply to new sources from day one; respect each site’s terms and prefer the platforms’ public job feeds over scraping pages.

8. Analytics (jobs-data) enhancements

8.1 Requested

Item	Plan
Seen-before (reposted) breakdown	A drill-down by employer: how many times, days between reposts, same or changed text. Reposting the same role every 30 days is a strong “ghost job” signal, so it feeds the employer card
Top employers, good and not-so-good	Two cards: Most applicant-friendly and Watch list. Measured on how applicants are treated (jobs open for months, reposts, roles closed without a sign of a hire, blocked status with a public note), not on volume. This is why CIBC looks good today: the current ranking rewards volume and freshness
ATS by employer	Already captured per posting in `posting_ats.ats_system`; add a roll-up view `jobs_api.employer_ats()` and show it on the employer card and the job page
Internal link	Every report row gets Open in AIDA Job Board beside the external link. Not signed in → the tenant’s sign-in / create-account page, returning to the job; signed in → Save to My Saved Jobs
Analytics per user type	Public (the market), end user (my searches against the market), data admin (their users’ activity, anonymous), system admin (collector health), app admin (all tenants)

8.2 Why 81,109 links say “Not checked”

The cause is in closed_checks.py, not in the data. The page check only looks at postings whose source is Company Career Page, and at most 300 pages a run. Postings from job boards and aggregators (Job Bank Canada, board scrapes and the like) are never selected, and employer-feed jobs are handled by the “gone from the list” rule without ever getting a link_status. So “Not checked” mostly means “never eligible”, not “failed”.

Fix, in order: 1. Show three numbers instead of one, by source: confirmed by list (employer feeds, seen in the last 3 days), checked page, and not eligible yet. 2. Write link_status = 'open' for jobs confirmed by their employer’s list, so feed jobs stop counting as unchecked. 3. Add a checker for Job Bank Canada (its posting pages say clearly when a job is gone), and raise CC_PAGE_MAX in steps while watching the browser load. 4. Age out: postings older than a set number of days with no sighting are marked stale instead of staying unchecked forever.

8.3 Built the Hub way (added 14 November 2026)

The analytics now follow the same method as the Live Reporting Dashboards: one KPI, one definition, one governed function that feeds the tile, chart, report and CSV; a full catalogue entry for every KPI; dashboards by profile; every number opening its records; a certification register; an end-to-end check against an independent engine; and an offline copy. The design is in AIDA_Job_Board_Analytics_Catalogue_v0.1.md (44 KPIs on 6 dashboards), with the machine-readable catalogue in AIDA_Job_Board_KPIs_v0.1.json in the blueprint’s DATA.kpis shape. It supersedes the “Analytics per user type” row in 8.1; 8.2 delivers KPIs D3-05 and D3-06.

9. Resume Builder

Built for students, newcomers and people who aren’t comfortable with technology. One question per screen on phones, a few on tablets.

About you: name, phone, email, city, links (prefilled from an uploaded resume when there is one).
Where you worked: employer, city, start and end month (dropdowns), job title, and three plain-language prompts (“What did you do most days?”, “What are you proud of?”, “Any numbers?”).
Skills: pick from a list matched to their job titles, plus their own; these fill the skills table and the ATS keyword list at the bottom, as in today’s format.
Top achievements: three short answers that build the Summary.
Education and certifications: school, program, year; certificate, issuer, year.
Pick one page or two. Out come DOCX, PDF and an ATS plain-text file, built by the existing resume formatting scripts, with the render check (last page full, no job block split across pages).

Standalone mode: the summary and bullets are assembled from their own words using templates, with no AI. Airlock Available mode: an optional “polish my wording” button, with PII tokenized first.

Uploaded resumes are parsed into the same child records, so editing online and saving a copy use the same screens.

10. Languages

English and French in every edition (decided), so every AIDA product is offered in both official languages from day one. More languages can be chosen when the portal is created or added later on request.
Every label, instruction, help article, email and error is a translation_strings row keyed by label_key.
Translation page: one page, filtered by language. For every key it shows the current English, the current translation, and a box for an updated translation, with “missing” and “English changed since translation” flags and a completeness bar per language.
Data admins manage languages and translations; the translator permission set allows editing assigned languages only.
French comes standard. The paid option becomes professional translation and upkeep of additional languages, plus a professional review of a client’s own French content (help text, emails, their own postings). French is essential for Boréal and for Quebec under Law 25 and the Charter of the French Language.

11. Compliance: portal-checklist.aidalabs.ca

One checklist page per portal, generated when the portal is created, with comments, evidence files, sign-off, and a Generate compliance report button (DOCX/PDF). The full privacy and hardening baseline for all products comes after the Job Board ships and will be built into this checklist and the Install Package template.

Laws and frameworks on the starter checklist (each tenant shows only those that apply):

Law / framework	Applies when
PIPEDA (federal private sector)	AIDA Labs and private-sector tenants, outside provinces with their own law for data that stays in the province
Bill C-36, Protecting Privacy and Consumer Data Act	Watch item. Introduced 15 June 2026 and before Parliament; it would replace Part 1 of PIPEDA, so the checklist tracks it without claiming it is law
Quebec Law 25 (Act respecting the protection of personal information in the private sector)	Quebec users or Quebec hosting (our Quebec server)
Alberta PIPA, BC PIPA	Tenants in those provinces
Ontario FIPPA	Ontario public colleges as clients (Boréal): they need us to meet their obligations as their service provider
CASL	Every notification and marketing email
AODA / WCAG 2.0 AA	Ontario clients; we should build to WCAG 2.1 AA for everyone
Ontario French Language Services Act, Quebec Charter of the French Language	Francophone and Quebec clients
Cross-border transfer	Any AI provider or service outside Canada (Airlock mode)

Each requirement row: law, section, the requirement in plain words, how this portal complies (or what must change), owner, evidence links, comments, status, reviewer, date. Every edit goes to the audit log.

12. The Project Install Package

Every new portal starts as a Project Install Package: a configured project plan, blueprint, custom project portal, collaboration board and compliance checklist, either hosted by us or delivered to the client’s server through AIDA Git (section 4.1).

Built on the Project Plan data model v0.1. What it adds:

Addition	Tables
The package itself	`install_package` (project, tenant, edition, offering, mode, languages, host, status, git repository, release)
Template source	`plan_template`, `template_element` (the Job Board work breakdown with placeholders), copied into `wbs_element` on spin-up
Collaboration board	`sprint`, `board_column` (Backlog, To do, In progress, Review, Done, Blocked), `board_card` (one per task, assigned automatically by role)
Audit trail	`task_comment`, plus the existing `status_history` and `audit_log`
Users with project titles	Existing `project_role`, `project_member`, `permission`, with server accounts created from them

Tracked: each package task, who completed it, when, and notes. Not tracked: every edit of every document.

Spin-up order (one script, new_jobboard.zsh <slug>): customer folder → PocketBase tenant from core + jobboard → skin → languages → plan from template with dates → board and first sprint, with cards assigned by role → checklist page → blueprint published from the plan snapshot → explainer stub → AIDA Git repository and client account (self-hosted offerings) → check script.

13. Apps

Decided: installable web apps (PWA) first, one per site, each carrying that site’s brand and opening on the home layout of the signed-in user’s profile. portal.aidalabs.ca already has the manifest and service worker to copy. Store apps (App Store, Google Play) come later, as a wrapper around the same app, once a paying client asks; each store listing costs review time and an annual developer fee.

14. The sites around it

Job Search Diner (aida-job-search.ca). The Diner becomes a real place: the job search is “on the menu”, AIDA the Ultimate Hostess greets visitors, the Data Queen’s analytics are “the specials board”, and the Watch list is “Dr. Agentic’s Most Wanted” (factual lines only, as the report card rule requires). Decided wording: “Watch list” on the professional sites, “Dr. Agentic’s Most Wanted” on the Diner. Promote it from the Drive-In (a concession-stand ad between features, “Now hiring at the Diner”) and from RMDb (each film’s page links its hiring theme to a live search). Keep it separate from aidalabs.ca, as already decided.

aidalabs.ca restructure (decided direction). The site is currently organised by kind of portal (Enterprise, AI-Enhanced, Small Business), but the portals really differ only in size. Restructure it around the real products: AIDA Studio, AIDA Coach, AIDA Project Portal, AIDA Project Plans, AIDA Software Rollout Blueprints, Live Reporting Dashboards, AIDA Job Board, AIDA AI Airlock, and the others. - Sizes become editions on each product page (for example Small Business / Professional / Enterprise), plus hosting (AIDA in Canada or the client’s own servers). - The AI Airlock becomes an add-on that can attach to any product, which matches the Job Board’s Standalone / Airlock Available modes. - Client work and sample demos hang off their product page (“See it live”). - The Job Board launches as the first product page in the new structure, with its explainer, the three offerings, the two modes and a link to job-board.aidalabs.ca.

jobs.aidalabs.ca. Replace the silver-haired AIDA with the raven-ponytail AIDA; the picture becomes the link to the job-seeker explainer (which should lead with ATS detection).

jobs-data.aidalabs.ca. A new one-minute explainer; the page picture becomes its link.

Manuals (learn.aidalabs.ca). One manual per profile (End User, Data Admin, System Admin, App Admin), plus a Translator quick guide. They’re written from the help_articles records so the in-app help and the manuals never drift apart.

15. Decisions

15.1 Decided (14 Nov 2026)

#	Decision
1	Product name: AIDA Job Board (section 1.1)
2	College demo: branded demo with the demonstration bar, links out to real pages, and the Prospect skin kit (section 3.1)
3	Profiles: the five profiles and six permission sets as listed (section 5)
4	Account approval: manual, domain auto-approve and auto-approve all are separate on/off switches; new tenants start with manual on (section 5.4)
5	Pool for self-hosted clients: snapshot included with offerings 2 and 3, plus a feed licence (section 4)
6	Languages: English + French in every edition (section 10)
7	Wording: “Watch list” on the professional sites, “Dr. Agentic’s Most Wanted” on the Diner (section 14)
8	Apps: PWA first, store apps later (section 13)
9	Build order: the Job Search Diner first (section 16)
10	Boréal: no date yet; the demo follows job-board.aidalabs.ca
11	Delivery: self-hosted AIDA Git (Forgejo) on Quebec, an account for each client, snapshot by expiring link outside git; stood up early and light, lower priority if it gets costly (section 4.1)
12	Collector expansion: consulting firms plus fitness, wellness and spa chains; readers per hiring platform, employers as config rows, Canada first (section 7.3)
13	aidalabs.ca restructured around real products, sizes as editions, Airlock as an add-on (section 14)

15.2 Still open

Boréal date: set when job-board.aidalabs.ca is ready to show.

16. Roadmap

Release	Contents	Gate
R0 Foundations	jobboard.yaml model, permission tests, link-check fix, employer cards rework, internal job links, federal collector relabelled, AIDA Git stood up (our own code first)	Permission tests pass; “not checked” explained on the page; our repos on git.aidalabs.ca
R1 Job Search Diner	aida-job-search.ca rebuilt as the Diner on the Job Board core (search, saved jobs, documents, EN/FR), Drive-In/RMDb promotion, jobs.aidalabs.ca AIDA swap, jobs-data explainer, collector expansion: discovery, new platform readers, consulting and fitness/wellness/spa employer lists	Preview approved; employer lists approved
R2 job-board.aidalabs.ca	The professional edition: account requests with approval switches, data admin panel, CSV loads, collector board, analytics by profile, EN/FR	Phone/tablet/desktop checks; preview approved
R3 Resume Builder	Wizard, DOCX/PDF/TXT, upload-and-edit	Five test users, including one non-technical, finish a resume in under 15 minutes
R4 Install Package	Templates, spin-up script, board, sprints, checklist portal, compliance report, AIDA Git client accounts, releases, snapshot links	A test tenant spun up end to end, including its repository and a test client account
R5 College demo	Prospect skin kit, Boréal demo, explainer	Your review before the password goes out
R6 Commercial	Offerings 2 and 3 packaging, snapshot terms, feed licence metering, plugin, manuals, aidalabs.ca restructure around real products with the Job Board launch, PWA per site	Plugin installs; manuals published; new site structure preview approved

The backlog CSV breaks every release into epics, stories and tasks with acceptance criteria and owner roles. A v0.2 backlog adds the items in section 0.

Sources