arckit-cli 6.1.1__py3-none-any.whl

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/ca-fitaa.md

@@ -0,0 +1,81 @@
+# Canada FITAA Compliance Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:ca-fitaa` generates a Canada Foreign Influence Transparency and Accountability Act (FITAA) compliance assessment under Bill C-70 (2024). It scopes registrable activity, designs the public-vs-protected arrangement register, lays out the registration workflow and severance rules, captures the Commissioner liaison protocol, and surfaces a Charter §2 risk register.
+
+The Office of the Commissioner of Foreign Influence Transparency is newly stood up. Regulations are still being made through 2025–2026, so this command treats unsettled section numbers and offence references as `<TBC at draft time>` placeholders that the reviewer must reconcile against the consolidated Justice Laws Website text before relying on the output.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | Activity description and arrangement triggers |
+| Stakeholders (`ARC-<id>-STKE-v1.0.md`) | Foreign principals, registrants, civil-society stakeholders |
+| Data requirements (`ARC-<id>-DR-v1.0.md`) | Register data fields, public vs protected flags |
+| Data model (`ARC-<id>-DMOD-v1.0.md`) | Arrangement / registrant / foreign-principal entities |
+
+---
+
+## Command
+
+```bash
+/arckit:ca-fitaa <project ID or service description>
+```
+
+Output: `projects/<id>/ARC-<id>-FITAA-v1.0.md`
+
+---
+
+## Assessment Structure
+
+| Section | Contents |
+|---------|----------|
+| Document Control | Canadian classification (UNCLASSIFIED / Protected A–C / CONFIDENTIAL / SECRET / TOP SECRET) |
+| Revision History | Version, date, author, changes, approvals |
+| Executive Summary | FITAA exposure, registration model, headline Charter §2 findings |
+| Activity Scoping | Statutory triggers, exclusions, decision tree mapped to project activities |
+| Arrangement Register Design | Per-field schema with Public / Protected flag, 14-day update cadence |
+| Registration Workflow | Submission, identity verification, acknowledgement, material-change update |
+| Public Register vs Protected Investigative Data | Data flow, severance rules, withdrawal / correction process |
+| Commissioner Liaison Protocol | Triggers, cadence, contacts, RCMP / CSIS coordination |
+| Charter Risk Register | s.2(b) chilling-effect and s.2(d) association mitigations with residual rating |
+| Compliance Schedule | Registrant-side triggers, 14-day clock, penalty exposures |
+| Open Items | Statutory currency caveats with `<TBC>` markers |
+| External References | Document Register, Citations, Unreferenced |
+
+---
+
+## When to run
+
+- A project introduces a registration or transparency scheme for arrangements with foreign principals.
+- A federal department is designing the public-facing FITAA register or its protected investigative back-end.
+- A programme touches advocacy, journalism, diaspora engagement, or political activity and needs to assess registrability.
+- A reviewer needs a structured Charter §2 risk register before service-design sign-off.
+
+---
+
+## Common pitfalls
+
+- **Confusing FITAA with the Lobbying Act or Conflict of Interest Act.** These are separate transparency regimes with different scopes and registrars; FITAA targets foreign-principal arrangements, not domestic lobbying.
+- **Treating Charter analysis as optional.** Any registration scheme that captures advocacy, journalism, or political activity is presumptively engaging Charter §2(b) and §2(d). The `ca-charter` handoff is unconditional.
+- **Conflating public and protected views.** The public register and the investigative back-end must be designed as separate logical systems with audited severance rules. Mixing them creates ATIP-Act exposure under §15 (national security) and §16 (law enforcement).
+- **Using stale statutory cites.** FITAA section numbering and offence references are still settling. Treat any unconfirmed cite as `<TBC at draft time>` and reconcile against the current Justice Laws text before publication.
+- **Skipping bilingual review.** The public-facing register, registration forms, acknowledgements, and notices must be available in both official languages. Skipping `ca-ola` produces a non-compliant artefact.
+
+---
+
+## Handoffs
+
+- **`ca-charter`** — Charter §2 expression and association analysis is required for any registration scheme that engages protected speech or association. Treat as unconditional after FITAA.
+- **`ca-pia`** — Privacy Impact Assessment for personal information collected during arrangement registration. Required before the system collects or processes registrant or foreign-principal personal data.
+- **`ca-atip`** — Reconciles the public-facing register against the protected investigative dataset; required severance design for hybrid public / protected views.
+- **`ca-aia`** — Algorithmic Impact Assessment is triggered when registration triage uses any automated decision-making, scoring, or risk classification.
+
+---
+
+## Statutory currency
+
+FITAA was enacted in June 2024 with regulations still emerging through 2025–2026. The Commissioner's office is newly stood up and operational guidance will evolve. Verify all citations against the current Justice Laws Website text and the Commissioner's published guidance before relying on this output. Where section numbers or offence references are unsettled, the template uses `<TBC at draft time>` placeholders that the reviewer must reconcile before publication.

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/ca-gc-digital-standards.md

@@ -0,0 +1,93 @@
+# Canada GC Digital Standards Conformance Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:ca-gc-digital-standards` generates a Government of Canada Digital Standards conformance scorecard for a federal digital service. It assesses the service against the 10 Digital Standards individually, surfaces evidence and gaps per standard, captures remediation actions with owners and target dates, and produces a per-standard maturity roadmap. Cross-cutting themes — accessibility, open data and code, ethical AI, user research practice — are scored once across the standards they touch.
+
+The Digital Standards are not aspirational principles. They sit under the TBS *Policy on Service and Digital* and the *Directive on Service and Digital*; ADMs are accountable for adherence and TBS audits conformance through the digital reporting cycle. Standard 6 is reinforced by the *Accessible Canada Act* and the *Accessible Canada Regulations*, which set the statutory floor regardless of how the digital scorecard reads. Treat this artefact as a delivery and governance gate — not a self-assessment exercise.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | Service description, user populations, intended outcomes |
+| Service assessment (`ARC-<id>-SAS-v1.0.md`) | GDS-style evidence base — many points map onto Digital Standards |
+| Retrospective notes | Iteration cadence, learning loops, team practices |
+| Accessibility audits | WCAG 2.1 AA / 2.2 AA conformance, manual and assistive-tech reviews |
+| PIA / AIA artefacts | Standard 5 (security and privacy) and Standard 9 (ethical) evidence |
+
+---
+
+## Command
+
+```bash
+/arckit:ca-gc-digital-standards <project ID or service description>
+```
+
+Output: `projects/<id>/ARC-<id>-DIGSTD-v1.0.md`
+
+---
+
+## Assessment Structure
+
+| Section | Contents |
+|---------|----------|
+| Document Control | Canadian classification (UNCLASSIFIED / Protected A–C / CONFIDENTIAL / SECRET / TOP SECRET) |
+| Revision History | Version, date, author, changes, approvals |
+| Executive Summary | Conformance posture across the 10 standards, top remediation actions, maturity headline |
+| Service Description | Service, owner, user populations, lifecycle stage, key artefacts |
+| Per-Standard Assessment | One sub-table per standard with Evidence, Gaps, Remediation, Owner, Target date, Maturity |
+| Cross-Cutting Themes | Accessibility, open data and code, ethical AI, user research — scored across the standards they touch |
+| Maturity Roadmap | Current vs target maturity per standard, milestones, owners, dates |
+| Open Items | Outstanding decisions, blocked remediations, deferred standards work |
+| External References | Document Register, Citations, Unreferenced |
+
+---
+
+## Maturity scale
+
+The scorecard uses a CMMI-style 5-level progression for each standard:
+
+| Level | Meaning |
+|-------|---------|
+| Initial | Practice is ad hoc, undocumented, or absent. Conformance is incidental rather than designed. |
+| Repeatable | Practice happens consistently on this service, but is informal and dependent on the current team. |
+| Defined | Practice is documented, standardised across the team, and onboarded into team rituals. |
+| Measured | Outcomes are instrumented; the team has metrics that prove conformance, not just activity. |
+| Optimising | The team uses the metrics to iterate the practice itself. Conformance improves over time without prompting. |
+
+Score each standard independently. Do not collapse the 10 dimensions into a single overall maturity number — that loses the per-standard signal TBS reviewers need.
+
+---
+
+## When to run
+
+- Pre-launch — before go-live for a new federal digital service to evidence conformance to all 10 standards.
+- ATO renewal — pair with `ca-itsg-33` and `ca-pia` so the security, privacy, and digital scorecards refresh together.
+- Quarterly governance review — TBS reporting cycles surface conformance gaps, so refresh the scorecard ahead of each cycle.
+- Substantive service change — new audience, new channel, new automated decision, new processor, or change of jurisdiction.
+
+---
+
+## Common pitfalls
+
+- **Treating the standards as advisory.** The Digital Standards are policy under the *Policy on Service and Digital*; non-conformance has audit consequences. Do not write the scorecard as a discretionary self-rating.
+- **Missing the WCAG / Accessible Canada Act floor.** Standard 6 is anchored in statute. WCAG 2.1 AA / 2.2 AA conformance is the operational target, and statutory accessibility plans, feedback processes, and progress reports are mandatory regardless of how the scorecard reads.
+- **Default-private working when "Work in the open" is the rule.** Standard 3 requires open-by-default. Reasons not to publish must be explicit, narrow, and time-boxed. Default-private is itself a non-conformance — remediate it, do not rationalise it.
+- **Uniform maturity claims rather than per-standard.** A service can be advanced on accessibility and immature on open code. The scorecard MUST report dimension-by-dimension; an aggregated overall maturity number is misleading and is not accepted by TBS reviewers.
+- **Confusing this with the GDS Service Standard.** The two regimes overlap conceptually but are governed differently. Use `service-assessment` for the GDS regime; this command is the GC-specific complement.
+
+---
+
+## Handoffs
+
+- **`service-assessment`** — Many of the GDS Service Standard points overlap with the GC Digital Standards (user research, accessibility, iteration, openness). The Digital Standards scorecard feeds the broader service-assessment evidence base directly; cross-link the same evidence rather than duplicating it. Where the regimes diverge (e.g. open-by-default, ethical AI), keep the per-standard treatment authoritative here.
+- **`roadmap`** — Identified gaps and remediation actions become roadmap milestones with owners, dates, and dependencies. Carry the per-standard maturity progression forward so the strategic roadmap shows how conformance improves over the planning horizon, not just feature delivery.
+
+---
+
+## Statutory currency
+
+The Digital Standards may be revised by TBS — the standards themselves and the *Directive on Service and Digital* both evolve, and the *Digital Operations Strategic Plan* is updated annually. The *Accessible Canada Regulations* expand in tranches across federal entities and reporting categories. Cite the version verified at the verification date in the Document Register, and re-verify on every refresh of the scorecard. Provincial accessibility regimes (AODA in Ontario, the BC Accessibility Act, Loi visant à favoriser l'intégration in Quebec) layer on top where the service has provincial reach — they require their own assessments and are out of scope here.

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/ca-itsg-33.md

@@ -0,0 +1,80 @@
+# Canada ITSG-33 Statement of Applicability Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:ca-itsg-33` generates an ITSG-33 Statement of Applicability for a Canadian federal information system. ITSG-33 is the *IT Security Risk Management: A Lifecycle Approach* publication issued by the Communications Security Establishment / Canadian Centre for Cyber Security and is the federal baseline for security control selection. The artefact this command produces walks through information-asset categorisation, control-profile selection, per-family applicability, cryptographic module validation, supply-chain screening, continuous monitoring, and the authorisation chain.
+
+The TBS *Standard on Security Categorization* sits upstream of ITSG-33 — it is the source of the injury-based Confidentiality / Integrity / Availability scoring matrix that produces the system-level categorisation (UNCLASSIFIED / Protected A / Protected B / Protected C / CONFIDENTIAL / SECRET / TOP SECRET). The categorisation drives every downstream choice, so the categorisation section is the load-bearing part of the artefact: get it wrong and the chosen control profile, the tailoring envelope, and the authorisation cycle all propagate the error.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | Functional context and NFR-SEC-* security requirements |
+| Data requirements (`ARC-<id>-DR-v1.0.md`) | Per-element sensitivity classifications feeding categorisation |
+| Privacy Impact Assessment (`ARC-<id>-PIA-v1.0.md`) | Personal-information drivers for the categorisation, especially Confidentiality scoring |
+| Statement of Initial Authority (`ARC-<id>-SOIA-v1.0.md`, if classified) | Classified-information envelope and lawful-handling chain |
+
+---
+
+## Command
+
+```bash
+/arckit:ca-itsg-33 <project ID or service description>
+```
+
+Output: `projects/<id>/ARC-<id>-ITSG-v1.0.md`
+
+---
+
+## Assessment Structure
+
+| Section | Contents |
+|---------|----------|
+| Document Control | Canadian classification (UNCLASSIFIED / Protected A–C / CONFIDENTIAL / SECRET / TOP SECRET) |
+| Revision History | Version, date, author, changes, approvals |
+| Executive Summary | System-level categorisation, chosen profile, tailoring posture, CMVP / supply-chain status |
+| Information Asset Categorisation | Per-asset C / I / A scores (Low / Medium / High), aggregated to system-level categorisation |
+| Control Profile Selection | PBMM / PBMM-Cloud / Secret-High / Top-Secret-High with rationale and tailoring summary |
+| Statement of Applicability | Per-family applicability across all 16 ITSG-33 control families (AC, AU, CA, CM, CP, IA, IR, MA, MP, PE, PL, PS, RA, SA, SC, SI) |
+| Cryptographic Module Validation | CMVP / FIPS 140-3 certificate per module, validation level, algorithm scope, status |
+| Supply Chain Security | Vulnerable Suppliers and sanctioned-entities screen across prime, sub-processors, equipment, managed services |
+| Continuous Monitoring Plan | Frequency, tooling, reporting cadence, re-categorisation triggers |
+| Authorisation Chain | System Owner → Security Authority → Authorising Official with cycle and conditions |
+| Open Items | Outstanding tailoring, unfinished CMVP checks, unresolved supplier flags |
+| External References | Document Register, Citations, Unreferenced |
+
+---
+
+## When to run
+
+- Pre-authorisation — generate the Statement of Applicability before the authorising official considers the package; an Authority to Operate cannot be granted without it.
+- ATO renewal — re-run at the published re-authorisation cycle (typical federal cycle is annual or triennial depending on categorisation).
+- Substantive change to the system or its operating environment — new data elements, new processing purposes, new operating environment (on-prem to cloud, region change), new supplier, or a security incident that materially changes the threat picture.
+
+---
+
+## Common pitfalls
+
+- **Under-scoring categorisation.** The temptation is to score down to keep the control envelope manageable. The TBS Standard is injury-based — score the realistic worst-case injury, not the convenient one. Under-scoring is the failure mode that propagates the furthest.
+- **Tailoring-by-preference.** Every deviation from the published CSE profile must be justified with a residual-risk statement and named acceptance. "We don't want to do this" is not a tailoring rationale; "the compensating control delivers equivalent or greater assurance because X" is.
+- **Non-CMVP cryptography slipping in.** Modules drift to *Historical* status on the CMVP list without a code change in the system. Verify each module against the active list at generation time, not the list that was current at procurement.
+- **Missing the Vulnerable Suppliers screen.** The *Direction on Vulnerable Suppliers* attaches to sub-processors and telecommunications equipment, not just the prime contractor. A clean prime with a flagged sub-processor is still flagged.
+- **Categorisation that does not match the PIA.** Personal-information sensitivity in the PIA must reconcile with the Confidentiality score in the ITSG-33 categorisation. Divergence is a finding by inspection.
+- **Continuous monitoring as a sign-off, not an operating mode.** Authorisation is conditional on the monitoring plan actually running. List the tooling, the cadence, and the role accountable for the evidence — otherwise the authorisation is brittle.
+
+---
+
+## Handoffs
+
+- **`ca-cloud-residency`** — The system-level categorisation and the chosen control profile are direct inputs to the sovereign cloud residency assessment. Cloud-hosted Protected B and above attracts a tighter residency envelope under the TBS *Direction on the Secure Use of Commercial Cloud Services*.
+- **`risk`** — Residual security risks from the SoA (Compensating Controls with residual risk, supplier flags with mitigation in place, cryptographic-module gaps awaiting resolution) flow into the operational risk register. Carry the same risk IDs forward so the residual posture is traceable.
+- **`adr`** — Material control tailoring decisions, compensating-control choices, and supplier-of-concern accommodations warrant Architecture Decision Records. The SoA captures the decision; the ADR captures the architectural rationale and the alternatives considered.
+
+---
+
+## Statutory currency
+
+ITSG-33 itself is comparatively stable but the surrounding TBS guidance moves: the *Direction on the Secure Use of Commercial Cloud Services* and the *Direction on Vulnerable Suppliers* both update on TBS cycles, and the CMVP active-modules list churns continuously. Cite the current versions of TBS guidance and verify each cryptographic module against the live CMVP list at the time of generation. Record the verification date in the Document Register so a reviewer can audit currency.

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/ca-ocap.md

@@ -0,0 +1,91 @@
+# Canada First Nations OCAP® Sovereignty Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:ca-ocap` generates a First Nations OCAP® (Ownership, Control, Access, Possession) sovereignty assessment for any federal information system that processes Indigenous data. The output is a per-dataset OCAP mapping anchored on the First Nations Information Governance Centre (FNIGC) framework, with separate tracks for Métis data (USAI principles) and Inuit data (ITK *National Inuit Strategy on Research*). It is not a substitute for direct engagement with FNIGC, the affected First Nation(s), Métis Nation governing members, or Inuit organisations.
+
+The command enforces a structural FNIGC pre-engagement gate. If the architect cannot confirm that an FNIGC pre-engagement is booked or in progress, the artefact remains a planning scaffold only — the per-dataset OCAP register, USAI / ITK considerations, DSA terms, repatriation plan, and co-governance arrangement are deferred until engagement is confirmed. OCAP is a relationship; the artefact records and supports the relationship rather than substituting for it.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | System scope and Indigenous-data triggers |
+| Data requirements (`ARC-<id>-DR-v1.0.md`) | Per-element collection / use / disclosure |
+| Data model (`ARC-<id>-DMOD-v1.0.md`) | Entity-level data classifications |
+| Privacy Impact Assessment (`ARC-<id>-PIA-v*.md`) | Privacy controls inherited; OCAP layers community sovereignty over the PIA's federal privacy posture |
+
+---
+
+## Command
+
+```bash
+/arckit:ca-ocap <project ID or service description>
+```
+
+Output: `projects/<id>/ARC-<id>-OCAP-v1.0.md`
+
+---
+
+## Assessment Structure
+
+| Section | Contents |
+|---------|----------|
+| Document Control | Canadian classification with community-protected override note |
+| Revision History | Version, date, author, changes, approvals |
+| Executive Summary | Indigenous data in scope, FNIGC engagement status, headline OCAP findings or planning-scaffold flag |
+| FNIGC Pre-Engagement Confirmation | Engagement status, contacts, nature; Planning Scaffold Mode checkbox; engagement-letter scaffold |
+| Indigenous Data Inventory | Per dataset: First Nation(s) of origin, data nature, custodianship, transfer history, sensitivity |
+| OCAP Principles Mapping | Per dataset: Ownership / Control / Access / Possession sub-tables |
+| USAI Considerations | Métis data: Utility, Self-Determination, Access, Inter-relationships |
+| ITK Principles Considerations | Inuit data: NISR principles per Inuit Nunangat region |
+| Data Sharing Agreement Terms | Indigenous co-signatory, purpose limitation, time-bound, revocability, audit rights, sub-processor restrictions |
+| Repatriation Plan | Per dataset: historical context, return / destroy decision, method, owner, date |
+| Co-Governance Arrangements | Body, Indigenous representation, decision rule, appeal pathway |
+| Risks and Mitigation Register | Cultural, legal, reputational risks with residual rating |
+| Open Items | FNIGC follow-up, classification overrides, USAI / ITK engagement gaps, DSA signatures, UNDRIP review |
+| External References | Document Register (FNIGC OCAP®, UNDRIP Act, USAI, ITK NISR, Privacy Act), Citations, Unreferenced |
+
+---
+
+## When to run
+
+- Any federal system processes administrative, statistical, traditional-knowledge, biological, image, audio, or video data originating from First Nations, Métis, or Inuit populations.
+- A project is in pre-engagement scoping and needs a planning scaffold to brief FNIGC and community contacts.
+- Pre-launch of any service that will hold Indigenous data, before the system goes live.
+- A substantive change to the data, custodianship arrangement, or sharing scope of an existing system holding Indigenous data.
+- A repatriation request or community-led review prompts a re-assessment of an existing system's OCAP posture.
+
+The earlier this command is run, the more useful the planning scaffold becomes — running `ca-ocap` once design is locked-in tends to surface community-protected classifications and possession arrangements that should have shaped the design itself.
+
+If the assessment exists in planning-scaffold mode for an extended period, treat the engagement gap itself as a delivery risk and escalate it through the project's risk register.
+
+---
+
+## Common pitfalls
+
+- **Treating OCAP as a checklist.** OCAP is a relationship. The artefact supports the relationship; it does not replace direct engagement with FNIGC and the affected nation.
+- **Collapsing First Nations, Métis, and Inuit into one regime.** OCAP applies to First Nations data; Métis data is governed by USAI; Inuit data follows ITK NISR. Maintain distinct engagement tracks and contacts.
+- **Skipping FNIGC pre-engagement.** The gate in step 5.1 is mandatory. If engagement is not confirmed, the artefact must remain a planning scaffold.
+- **Assuming federal authority overrides community sovereignty.** It does not. Community-protected classifications can exceed the federal scheme; record the override and raise an Open Item.
+- **Permitting secondary analysis without renewed consent.** Each new use requires a renewed community consent path; do not rely on the original collection consent.
+
+---
+
+## Handoffs
+
+- **`data-model`** — OCAP-mapped data classifications and access controls feed the data model's stewardship and access policies. Where a dataset is community-controlled, the data model must record the controlling body and the access tier.
+- **`ca-pia`** — Personal-information processing of Indigenous data inherits the federal PIA controls plus OCAP-derived restrictions. Run `ca-pia` if any personal information is in scope; the OCAP register layers community sovereignty on top of the PIA's federal privacy posture.
+- **`ca-atip`** — ATIP severance design must reflect OCAP access and control determinations for Indigenous datasets. Where access is community-controlled, ATIP exemptions and severance must align so federal access requests do not bypass community decision authority.
+
+---
+
+## Statutory currency
+
+The *United Nations Declaration on the Rights of Indigenous Peoples Act* (S.C. 2021, c. 14) commits the Crown to align federal laws with the Declaration through an evolving Action Plan. Cite the current Action Plan version published by the Department of Justice. FNIGC training and guidance is the authoritative source on OCAP® application; verify the current FNIGC course and guidance pages before relying on the output. USAI guidance evolves through the Métis Nation Council and provincial governing members; ITK guidance evolves through the *National Inuit Strategy on Research* and the Inuit-Crown Partnership Committee.
+
+---
+
+OCAP® is a registered trademark of the First Nations Information Governance Centre. This command and the artefacts it produces support — but do not substitute for — direct, respectful engagement with FNIGC, the affected First Nation(s), Métis Nation governing members, and Inuit organisations. Treat every assessment as a record of an ongoing relationship rather than a one-time governance checkpoint.

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/ca-ola.md

@@ -0,0 +1,80 @@
+# Canada Official Languages Act Review Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:ca-ola` generates an Official Languages Act review for a federal digital service. It builds a service surface inventory across every user-facing channel, scores Parts IV (services), V (language of work), and VI (federal language obligations) of the *Official Languages Act* (R.S.C., 1985, c. 31 (4th Supp.)), captures the active-offer mechanism per surface, runs an equivalent-quality assessment to surface "translation lag" risk, documents the Translation Bureau pipeline, and acknowledges OQLF *Charter of the French Language* considerations where the service has Quebec exposure.
+
+The Act was substantively amended by *An Act for the Substantive Equality of Canada's Official Languages* (S.C. 2023, c. 15) — Bill C-13. The amendments expand the *Air Canada Public Participation Act*, sharpen federal-undertaking employer rules, and reinforce Part VII positive measures. Several provisions are still phasing in via Order in Council, so cite the consolidated post-2023 text and track outstanding commencements at every refresh. Treat this artefact as a delivery and governance gate — Part IV obligations attach to public-facing surfaces, Part V to internal tooling in designated bilingual regions, and Part VI to staffing impact wherever the system supports HR or staffing decisions.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | Service description, user populations, surfaces in scope |
+| Service assessment (`ARC-<id>-SAS-v1.0.md`) | Bilingualism evidence and active-offer posture |
+| FITAA assessment (`ARC-<id>-FITAA-v1.0.md`) | Any public register triggers Part IV bilingual obligations |
+
+---
+
+## Command
+
+```bash
+/arckit:ca-ola <project ID or service description>
+```
+
+Output: `projects/<id>/ARC-<id>-OLA-v1.0.md`
+
+---
+
+## Assessment Structure
+
+| Section | Contents |
+|---------|----------|
+| Document Control | Canadian classification (UNCLASSIFIED / Protected A–C / CONFIDENTIAL / SECRET / TOP SECRET) |
+| Revision History | Version, date, author, changes, approvals |
+| Executive Summary | OLA posture across Parts IV/V/VI, active-offer mechanism, top remediation actions |
+| Service Description | Service, owner, audience, lifecycle stage, bilingual designation basis |
+| Service Surface Inventory | Every user-facing surface with language posture, audience, channel, and active-offer mechanism |
+| Part IV — Communications and Services | Bilingual obligation rationale, active offer, bilingual capacity, status |
+| Part V — Language of Work | Tool / system per region, designated language posture, supervision language |
+| Part VI — Federal Language Obligations | Equitable participation, non-discrimination, staffing, career development |
+| Equivalent Quality Assessment | Content depth, usability, response time, release cadence per surface |
+| Translation Pipeline | Lead time, cadence, owner, release-gate per content class |
+| OQLF Acknowledgement | Quebec exposure, OQLF consideration, federal supremacy note |
+| Risk and Mitigation Register | Complaint exposure, court remedies under Part X, reputational risk |
+| Open Items | Outstanding decisions, deferred remediations, owners, review dates |
+| External References | Document Register, Citations, Unreferenced |
+
+---
+
+## When to run
+
+- Pre-launch — before go-live for any new federal digital service that has public-facing surfaces or internal tooling in a designated bilingual region.
+- Pre-major-release — any substantive change to surfaces, content models, IVR scripts, or release cadence.
+- New region of operation — when the service starts operating in a designated bilingual region or in Quebec, where OQLF acknowledgement attaches.
+- Quarterly governance review — refresh the active-offer evidence and the Translation Bureau lead times so the pipeline remains predictable.
+
+---
+
+## Common pitfalls
+
+- **Passive signage as active offer.** A bilingual sign on the wall is not active offer. The greeting, the screen, the IVR opening, and the written initiation must all extend the offer before the user has to ask. Active offer is a verb.
+- **"Translation lag" releases.** Shipping the English version first and promising the French version "soon" violates the OLA. Equal quality means release-gating in both languages — same content depth, same usability, same response times, same release cadence.
+- **Part V invisibility for internal tooling.** Public-facing surfaces dominate the conversation, but Part V obligations attach to internal tools in designated bilingual regions and to the language of supervision. Audit the back office, not only the storefront.
+- **Missing OQLF acknowledgement for Quebec-located services.** OQLF does not bind federal entities, but it does bind their Quebec-based suppliers. Document the parallel obligation in the supplier brief; do not assume federal supremacy makes the OQLF question disappear.
+- **Treating Bill C-13 as fully in force.** The substantive-equality amendments include provisions still phasing in via Order in Council. Cite the consolidated post-2023 text and track the commencement schedule at every refresh.
+
+---
+
+## Handoffs
+
+- **`ca-gc-digital-standards`** — OLA service equivalence is a baseline expectation under the GC Digital Standards conformance scorecard. Cross-link the Part IV active-offer evidence and the equivalent-quality assessment into the digital-standards artefact so the two regimes share evidence rather than duplicating it.
+- **`service-assessment`** — The OLA review feeds the service assessment evidence base for bilingualism and active offer. The same surface inventory and active-offer mechanism populate the GDS-style assessment for the user-research and accessibility points; carry the per-surface posture forward.
+
+---
+
+## Statutory currency
+
+Bill C-13 (2023) commencements are still phasing in via Order in Council, so cite the consolidated post-2023 text of the *Official Languages Act* and record any provisions not yet in force at the verification date in the Document Register. The Commissioner of Official Languages publishes operational guidance regularly and adjusts complaint patterns in response — refresh the OLA review on every substantive surface change, and at every quarterly governance review cycle. The OQLF *Charter of the French Language* evolves independently of federal law; track Quebec-side amendments where the service has Quebec exposure even though the federal entity is not directly bound.

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/ca-pia.md

@@ -0,0 +1,83 @@
+# Canada Privacy Impact Assessment Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:ca-pia` generates a Canada federal Privacy Impact Assessment (PIA) under the Privacy Act (R.S.C., 1985, c. P-21) and the TBS Directive on Privacy Impact Assessment. It scopes the programme, establishes lawful authority for collection, builds a per-element personal information inventory, runs an Oakes-derived necessity and proportionality analysis, registers privacy risks with mitigations, captures Privacy Act §7/§8 disclosure rationale, and surfaces the OPC notification decision.
+
+A federal PIA is mandatory for any new programme or substantial modification involving personal information, and the TBS Directive requires notification of the Office of the Privacy Commissioner at least 30 days before launch. The artefact this command produces is therefore not optional — treat it as a delivery gate, not a sign-off formality. Where lawful authority is unclear, mark it `<TBC>` and resolve before launch: collection without statutory authority is not lawful under §4 of the Privacy Act.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | Programme description, processing activities, decision logic |
+| Data requirements (`ARC-<id>-DR-v1.0.md`) | Per-element personal information inventory and sensitivity flags |
+| Data model (`ARC-<id>-DMOD-v1.0.md`) | Entities and relationships carrying personal information |
+| Stakeholders (`ARC-<id>-STKE-v1.0.md`) | Subject populations, partner agencies, processors |
+
+---
+
+## Command
+
+```bash
+/arckit:ca-pia <project ID or service description>
+```
+
+Output: `projects/<id>/ARC-<id>-PIA-v1.0.md`
+
+---
+
+## Assessment Structure
+
+| Section | Contents |
+|---------|----------|
+| Document Control | Canadian classification (UNCLASSIFIED / Protected A–C / CONFIDENTIAL / SECRET / TOP SECRET) |
+| Revision History | Version, date, author, changes, approvals |
+| Executive Summary | Programme, lawful authority posture, headline privacy risks, OPC notification decision |
+| Programme / System Description | Description, owner, subject populations, lifecycle stage, personal information lifecycle |
+| Lawful Authority | Privacy Act §4 collection authority and the enabling statute or regulation |
+| Personal Information Inventory | Per-element source, purpose, sensitivity, retention, disclosure recipients, PIB ref |
+| Necessity and Proportionality | Oakes four-step: pressing and substantial objective, rational connection, minimal impairment, proportional effects |
+| Privacy Risks and Mitigations | Risk register with likelihood, impact, mitigations, residual |
+| Transfers and Disclosures | §7 use, §8 disclosure with §8(2)(a)–(m) routine-use mapping, cross-border flags |
+| Individual Rights | §12 access, §13 PIB registration, correction, complaint to OPC |
+| OPC Notification Trigger Analysis | Trigger-by-trigger NOTIFY / N/A decision and date |
+| PIA Approval Chain | ATIP coordinator → ADM → head of institution, OPC and TBS notifications |
+| Action Tracker | Open mitigations with owner, due date, status |
+| External References | Document Register, Citations, Unreferenced |
+
+---
+
+## When to run
+
+- A new federal programme or service is being designed and personal information will be collected, used, or disclosed.
+- A substantial modification is proposed: new data elements, new purposes, new disclosure recipients, change of contractor or processor, change of jurisdiction (including cloud region).
+- Pre-launch — at least 30 days before go-live to satisfy the TBS Directive's OPC notification window.
+- A previous PIA needs to be refreshed because the programme has materially evolved or sensitivity classification has changed.
+
+---
+
+## Common pitfalls
+
+- **Treating PIA as a one-shot artefact.** The PIA is a living document. Re-trigger it on substantial modifications — new data, new purpose, new recipient, new processor, new jurisdiction.
+- **Missing the OPC 30-day window.** The TBS Directive requires notification at least 30 days before launch for new programmes or substantial modifications. Build the OPC review window into the delivery plan from the start.
+- **Using PIPEDA framing for a federal programme.** PIPEDA is the federal private-sector regime. The Privacy Act governs federal public-sector institutions. They have different lawful-basis structures, different disclosure rules, and different oversight bodies — do not cross-cite them as if interchangeable.
+- **Under-citing lawful authority.** A vague reference to a programme name is not statutory authority. Cite the enabling statute or regulation that authorises collection. If there is none, mark `<TBC>` and treat it as a launch blocker.
+- **Forgetting the Personal Information Bank.** PIB registration in TBS InfoSource is required under §13. An unregistered PIB undermines the §12 access right and exposes the institution.
+- **Conflating §7 and §8.** §7 governs use after collection; §8 governs disclosure to third parties. Each §8(2)(a)–(m) routine-use letter must match the actual disclosure scenario — do not aggregate dissimilar disclosures under one letter.
+
+---
+
+## Handoffs
+
+- **`risk`** — PIA findings feed the privacy and regulatory entries in the project-level risk register. Carry the Privacy Risks and Mitigations table forward with the same risk IDs so the residual posture is traceable.
+- **`ca-atip`** — The personal-information disclosure register continues into the Access to Information / Privacy Act reconciliation. The same severance and disclosure rules drive both the §12 access response and the broader ATIP regime.
+- **`ca-aia`** — Required when automated decision-making touches personal information. The Algorithmic Impact Assessment inherits the PIA personal-information inventory; do not duplicate, link.
+
+---
+
+## Statutory currency
+
+The Privacy Act is comparatively stable, but the TBS Directive on Privacy Impact Assessment evolves and the OPC issues operational guidance regularly. Cite the current version of the Directive (TBS Doc ID 18308) and the most recent OPC guidance documents at the time of generation, and record the verification date in the Document Register. Provincial privacy regimes (Loi 25 in Quebec, FIPPA in Ontario, BC PIPA, etc.) layer on top where the programme involves provincial or private-sector partners — those require their own assessments and are out of scope for this PIA.

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/ca-pspc.md

@@ -0,0 +1,96 @@
+# Canada Federal Procurement Strategy Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:ca-pspc` generates a federal Canadian procurement strategy under the Public Services and Procurement Canada (PSPC) *Supply Manual*. It scopes the procurement, applies the *Canadian Free Trade Agreement* (CFTA), CETA, CPTPP, and WTO-AGP threshold matrix, evaluates the Standing Offer / Supply Arrangement / AgileIQ / bespoke RFP / set-aside route landscape, captures the Procurement Strategy for Indigenous Business (PSAB) contribution to the departmental 5% rolling target, builds the security-clearance lead-time picture, sets out the evaluation-framework dimensions, and lays a bid-solicitation schedule consistent with Supply Manual standstill and debriefing rules.
+
+PSPC is the federal contracting authority for most goods and services procurements above departmental delegations. Federal procurement operates under a layered set of trade-agreement obligations — CFTA domestically, CETA / CPTPP / WTO-AGP internationally — and a Procurement Strategy for Indigenous Business that targets a 5% rolling departmental contribution to Indigenous-business procurement. Treat this artefact as a delivery gate: the route, the trade-agreement coverage, the PSAB posture, and the clearance-lead-time picture must be set before market engagement, because reversing them after a posting attracts CITT review and rework cost.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | Scope, value drivers, integration surface |
+| Strategic outline business case (`ARC-<id>-SOBC-v1.0.md`) | Affordability envelope, commercial case, route hypothesis |
+| ITSG-33 control profile (`ARC-<id>-ITSG-v1.0.md`) | Security control profile drives clearance posture and supplier security obligations |
+| Cloud residency assessment (`ARC-<id>-CACR-v1.0.md`) | Sub-processor analysis and CSP shortlist where cloud is in scope of the procurement |
+
+---
+
+## Command
+
+```bash
+/arckit:ca-pspc <project ID or service description>
+```
+
+Output: `projects/<id>/ARC-<id>-PROC-v1.0.md`
+
+---
+
+## Assessment Structure
+
+| Section | Contents |
+|---------|----------|
+| Document Control | Canadian classification (UNCLASSIFIED / Protected A–C / CONFIDENTIAL / SECRET / TOP SECRET) |
+| Revision History | Version, date, author, changes, approvals |
+| Executive Summary | Recommended route, binding trade agreements, PSAB posture, longest clearance lead time, blocking open items |
+| Procurement Scope | Goods/services breakdown, estimated value, term, options |
+| Threshold Analysis | CFTA, CETA, CPTPP, WTO-AGP coverage and open-tendering obligations; set-aside carve-outs |
+| Route Selection | Standing Offer / Supply Arrangement / AgileIQ / RFP / set-aside fit, risk, timeline |
+| Procurement Strategy for Indigenous Business | Set-aside decision, sub-contracting plan, departmental 5% contribution |
+| Security Clearance Requirements | Per-role clearance level, lead time, critical-path posture |
+| Evaluation Framework Outline | Mandatory / point-rated / financial dimensions and weight envelope |
+| Bid Solicitation Schedule | Milestones from market engagement to award, with standstill and debriefing |
+| Risks | Supplier-pool, clearance, threshold, instrument-shape, CITT, residency, OLA / accessibility risks |
+| Open Items | Outstanding decisions, instrument confirmations, owners, review dates |
+| External References | Document Register, Citations, Unreferenced |
+
+---
+
+## When to run
+
+- After SOBC — once the affordability envelope and commercial case are set, the route and instrument can be sized.
+- Before market engagement — the route, the trade-agreement coverage, and the PSAB posture must be set before any RFI / Industry Day to avoid contradictory market signals.
+- After a material scope or value change — a procurement designed against last quarter's scope can fall on the wrong side of a CFTA / CETA / CPTPP / WTO-AGP threshold when value moves.
+- Pre-posting refresh — re-verify thresholds at posting; thresholds adjust biennially and trade-agreement coverage evolves.
+- Before contract extension or option exercise — option years roll value past thresholds and may re-trigger trade-agreement obligations even when the base award sat below them.
+
+---
+
+## Route shortlist at a glance
+
+| Need | First-look instrument | Notes |
+|------|-----------------------|-------|
+| Outcome-based informatics solution | SBIPS | Confirm scope notice covers the deliverable shape |
+| Resource-based informatics task | TBIPS | Resource-classification stream and security clearance must match |
+| Multi-disciplinary professional services | ProServices | Useful when scope spans multiple professional categories |
+| AI / data professional services | SA-AIDP | Newer instrument; confirm currency and renewal status |
+| Cybersecurity services | SA-Cyber | Confirm clearance prerequisites in the supply arrangement |
+| Iterative scope, rapid award | AgileIQ / Agile Procurement Process | Requires scope expressible as iterative task statements |
+| No instrument fits | Bespoke RFP / RFSO / RFSA | Justify against the scope, value, and evaluation model in the route-selection table |
+| Indigenous-business participation | PSAB set-aside or sub-contracting plan | Validate supplier pool through Indigenous Services Canada directory |
+
+---
+
+## Common pitfalls
+
+- **Defaulting to a Standing Offer without CFTA analysis.** A Standing Offer is still subject to trade-agreement obligations and CITT review. Choose the instrument by fit to scope, value, and evaluation model, not by the convenience of an existing call-up mechanism.
+- **Missing PSAB consideration entirely.** Even where a set-aside is not used, the PSAB analysis must be documented — the supplier-pool assessment, the carve-out reasoning, and the contribution to the departmental rolling 5% target. Silence on PSAB reads as oversight.
+- **Under-budgeting clearance lead time.** Top Secret and SCI clearances commonly take 6 to 12 or more months for new applicants. A schedule that assumes weeks rather than months attracts a critical-path risk that can reset the whole award timeline.
+- **Conflating ITQ, ITT, and RFP shapes.** Each solicitation form has different evaluation rules, different bidder rights, and different challenge pathways. Choose the form against the route-selection table; do not mix vocabulary across the artefact.
+- **Treating PSAB 5% as a per-procurement target.** The 5% is a department-level rolling target. Any one procurement contributes to it; no single procurement is judged against 5% in isolation. Document the contribution explicitly so the departmental return rolls up correctly.
+
+---
+
+## Handoffs
+
+- **`evaluate`** — PSPC route selection feeds the vendor evaluation framework's scoring rubric. The high-level mandatory / point-rated / financial dimensions and weight envelope set here are inherited by the detailed evaluation rubric, where per-criterion scoring guidance and mandatory-evidence requirements live.
+- **`sobc`** — The procurement strategy feeds the Strategic Outline Business Case's procurement and commercial pillars. The recommended route, the trade-agreement coverage, the PSAB posture, and the clearance-lead-time picture inform the affordability envelope and the commercial-case narrative; cross-link rather than duplicate.
+
+---
+
+## Statutory currency
+
+CFTA thresholds adjust biennially and the international agreements (CETA, CPTPP, WTO-AGP) carry their own coverage schedules and threshold cycles. Re-verify the current thresholds at the verification date in the Document Register; a procurement designed against last year's thresholds can fall on the wrong side of an obligation when posted. PSPC Standing Offers and Supply Arrangements cycle through renewals — re-verify the current instrument numbers (SBIPS, TBIPS, ProServices, SA-AIDP, SA-Cyber, and others) at posting, since a lapsed instrument reference invalidates the call-up. The PSAB is administered by Indigenous Services Canada and the registered supplier directory evolves; check the directory before relying on supplier-pool sufficiency for a set-aside decision.