Capabilities

A workflow built around how GC procurement files actually take shape.

The system supports business and IT teams during the pre-procurement stage, before the file is formally engaged. Its role is to give those teams a more disciplined starting point — not to make procurement determinations.

The workflow

A typical session moves through eight considerations. Each step is advisory; each step surfaces what was assumed and what still needs an authoritative answer.

1.
Intake and requirement shaping
The user describes an emerging requirement in plain language. The system asks scoping questions where ambiguity could later create risk — particularly around scope, dependencies, and the line between business need and proposed solution.
2.
Threshold and value framing
Total estimated requirement, including foreseeable expansions, is examined against contract-value thresholds. Lifecycle value, base periods, and option years are surfaced rather than allowed to drift into value-aggregation territory.
3.
Trade agreement coverage
Coverage under CFTA, CETA, CPTPP, WTO-GPA, and the bilateral free trade agreements is evaluated against commodity classification, entity coverage, and any applicable sector exclusions.
4.
Competition method considerations
Competitive and non-competitive paths are examined. Where a sole-source position is being considered, the proposed Government Contracts Regulations exception is tested against the encoded rules. Findings are advisory and subject to procurement officer review.
5.
Procurement vehicle mapping
Mandatory and recommended PSPC instruments — SaaSSA, SLSA, TBIPS, ProServices, NMSO — are mapped against the commodity and value envelope. Where a mandatory vehicle is implicated, that is named; where it is not, the file is left open for procurement direction.
6.
Policy overlays and governance triggers
Security (ITSG-33-aligned controls, SA&A, TRA), privacy (PIA), accessibility (WCAG 2.1 AA, EN 301 549), official languages, Indigenous procurement (PSIB), Buy Canadian, and cloud / data-residency considerations are surfaced based on the requirement profile.
7.
Unknowns and assumptions
Facts that the system was not given — and that, if assumed, would shape compliance conclusions — are surfaced as open assumptions or open questions. They are not silently resolved.
8.
Structured advisory record
The user leaves with a structured record of the analysis performed, the assumptions made, the unknowns flagged, and the issues requiring confirmation — designed to support the next conversation with procurement, contracting, legal, security, privacy, or accessibility advisors.

Coverage

The rule layer is built around encoded Government of Canada procurement policy. The areas below describe what the system is currently designed to reason about; they are not vanity metrics. The model is versioned and is updated as Treasury Board, PSPC, and trade-agreement instruments evolve.

Procurement vehicles

SaaSSA (Software-as-a-Service Supply Arrangement)
SLSA (Software Licensing Supply Arrangement)
TBIPS (Task-Based Informatics Professional Services)
ProServices
National Master Standing Offers (NMSO)

Trade agreements

Canadian Free Trade Agreement (CFTA)
CETA, CPTPP, WTO-GPA
Bilateral free trade agreements

Governance pillars

Security (ITSG-33-aligned controls, SA&A, TRA)
Privacy (PIA)
Accessibility (WCAG 2.1 AA, EN 301 549)
Official Languages
Indigenous Procurement (PSIB)
Buy Canadian and Green Procurement

Decision frameworks

Government Contracts Regulations, including the Section 6 exception bases
Treasury Board procurement policy notices
PSPC mandatory commodity strategies

How the system structures advisory input

The examples below show how the system structures advisory input. They are illustrative and are intended to support professional review by procurement, legal, security, privacy, and accessibility advisors. They are not procurement determinations.

Requirement shaping

“We need project management software for 200 users across 5 provinces. Budget is around $500K over 3 years. It will handle internal team data.”

Based on the facts provided, this looks like a SaaS requirement with a likely SaaSSA fit. At an estimated $500K over three years, the CFTA and CETA thresholds appear to be triggered, which would point toward a competitive process. Before going further, two things should be confirmed: whether any of the internal team data includes personal information — which would affect whether a PIA is required — and the appropriate security categorization for the data involved. Both questions should be confirmed with your departmental security and privacy advisors.

Illustrative. The system framed the considerations; vehicle, competition method, and governance gates remain subject to procurement officer and departmental review.

Threshold and value framing

“We are doing a $35K proof of concept with a particular SaaS product. If it goes well, we expect to roll it out department-wide — probably $400K total.”

Based on the facts provided, the total foreseeable requirement appears to be around $435K, not $35K. At that lifecycle value, CFTA and CETA thresholds appear to be triggered, which means treating the proof of concept as an isolated $35K acquisition would carry value-aggregation risk. A structured alternative would be one competitive process now with a base period (proof of concept) and option years (full deployment) — but the actual procurement approach is a matter for the procurement officer to confirm.

Illustrative. The system surfaces the value-aggregation pattern; whether and how to address it is a procurement officer determination.

Sole-source review

“My consultant says we can run a $25K pilot as sole source and then keep the vendor for several years using an ‘only one vendor can meet the requirement’ exemption. Is that approach defensible?”

Based on the facts provided, that approach would warrant careful review. A $25K limited-tender position under GCR 6(b) is only intended for requirements whose total foreseeable value sits within the Low Dollar Value cap; if multi-year use is already anticipated, the pilot and later years would normally be treated as one requirement. The GCR 6(d) exception is also narrow: it is intended for situations where no other supplier in the market can meet the need. A more conservative path would be one competitive process now, structured with a base period (pilot) and option years (rollout). Confirmation with the procurement officer and contracting authority is required before acting on any of this.

Illustrative. The system structures the considerations; the determination is for the procurement officer and contracting authority.

What it will not do

The system is designed around explicit boundaries. It does not make procurement determinations. It does not approve files. It does not replace any of the advisors a procurement file would normally pass through. It does not silently fill in missing facts in order to produce a tidier answer.

Where a fact would change the compliance picture, the system surfaces it as an open assumption or open question and leaves the resolution to the appropriate authority.

See it on a representative scenario