From Intent to Defensible Procurement
A decision-support platform for Government of Canada IT procurement.
The Brief
In the Government of Canada, the highest-risk procurement decisions happen earliest — when intent is vague, scope is fuzzy, and rules are applied inconsistently. By the time a requirement reaches PSPC, the logic gaps are already embedded and expensive to fix.
This platform helps teams structure their procurement thinking early. It translates ambiguous business intent into structured, auditable outputs — identifying applicable procurement vehicles, trade agreement obligations, governance requirements, and security implications from an initial description of need.
Ask it whether a mixed SaaS-and-services deal should be split or bundled, and it will walk you through vehicle selection, trade agreement thresholds, governance obligations (PIA, TRA, SA&A, data residency, official languages, accessibility), Indigenous procurement considerations, conflict-of-interest controls, and how to structure the RFP — with source citations for every obligation it references.
The system is grounded in a curated knowledge graph of real GC procurement policy — not general-purpose AI training data. It covers SaaS procurement, commercial off-the-shelf software, professional services (TBIPS), sole-source evaluation, product research, and compliance across the four governance pillars: Security, Privacy, Accessibility, and Official Languages.
It is not right 100% of the time. Every output includes source citations so claims can be verified, and the system is designed for professional review — not blind acceptance.
Scope
- Procurement Planning & Advisory
- Start with vague intent — "we need something like Jira for 200 people" — and the system identifies the applicable procurement vehicle, trade agreement triggers, governance obligations, and security classification. It asks clarifying questions where ambiguity creates risk.
- Statement of Work Generation
- Generates product-neutral SOWs with mandatory and rated requirements, the four compliance pillars, evaluation criteria, and inline source citations. Requirements are built from actual product feature analysis, not generic templates.
- TBIPS Professional Services
- A complete workflow for IT professional services procurement covering 93 TBIPS categories. Graph-sourced tasking, ceiling rates, linked deliverables, and cost estimates. Supports structured delta modifications with full traceability.
- Policy & Compliance Guidance
- Ask whether a requirement is SaaS, professional services, or a mix — and get a structured analysis covering vehicle selection, governance gates, trade agreement thresholds, PSIB obligations, conflict-of-interest controls, and contract structure. Every obligation is traced to specific GC directives, not training data.
- Sole-Source & Value Analysis
- Tests whether a proposed sole-source justification holds up against GCR 6(a)-(d) exceptions and trade agreement obligations. Detects value aggregation risks — catching foreseeable expansions that trigger competitive requirements.
- Product Research & Neutrality
- Researches actual product features and translates them into vendor-neutral functional requirements. An automated neutrality engine maps 86+ vendor terms to product-neutral descriptions for fair competition.
Process
- 1.
Describe the business need
Start with what you know — even vague intent. The system identifies applicable vehicles, trade agreement obligations, and governance requirements.
- 2.
Structure the procurement logic
A guided process captures security level, data sensitivity, capabilities, comparables, and services. Choices that trigger policy obligations are flagged immediately.
- 3.
Review governance gates
Deterministic compliance checks enforce security classification, personal information status, and governance acknowledgments. These gates cannot be bypassed.
- 4.
Generate defensible artifacts
Produces a Statement of Work with product-neutral requirements, compliance pillars, evaluation criteria, and inline source citations traceable to specific policy.
In Practice
Real conversations. The kind of guidance you'd get from a senior colleague who knows GC procurement policy.
Policy Analysis
“My consultant says I can run a pilot for $25K sole source and then keep the vendor for several years using an ‘only one vendor can meet the requirement’ exemption. Is that correct?”
No — that advice would put you at real audit risk. A $25K pilot under GCR 6(b) is only valid if the total foreseeable requirement is genuinely limited to that pilot. If you already expect multi-year use, the pilot and later years are one requirement — splitting them is value aggregation. And GCR 6(d) is very narrow: you must demonstrate no other supplier in the market can meet the need, not just that the incumbent is convenient. The compliant approach: run one competitive process now with a base period (pilot) and option years (rollout). That respects trade agreement thresholds and keeps the file defensible.
Produced in under a minute, with 3 source citations to the Government Contracts Regulations and trade agreements.
Planning
“We need project management software for 200 users across 5 provinces. Budget is around $500K over 3 years. It'll handle internal team data.”
I can help structure this. Based on what you've described: this is likely a SaaSSA procurement. At $500K, CFTA and CETA thresholds are triggered, so you'll need a competitive process. The internal team data suggests at least Protected A — can you confirm if any of this data includes personal information? That would affect whether a PIA is required.
Risk Detection
“We're doing a $35K proof of concept with Slack. If it goes well, we'll roll it out department-wide — probably $400K total.”
This is a value aggregation flag. Because the $400K expansion is reasonably foreseeable, your total requirement is $435K — not $35K. CFTA and CETA thresholds are triggered. The compliant approach: run one competitive process now, structured with a base period (POC, $35K) and option years (full deployment, $400K).
SOW Generation
“Generate a SOW for Figma. 100 users, Protected B, design team in Ottawa.”
I'll build this out. For Protected B with 100 users, I need to confirm: Does the design work involve any citizen-facing content or personal information? Once confirmed, I'll research Figma's actual features, translate them to vendor-neutral requirements, identify comparables, and generate a SOW with TRA/SA&A requirements, Canadian data residency, and WCAG 2.1 AA compliance.
Questions
No. This is a decision-support tool, not a decision-making tool. It produces draft artifacts and surfaces policy considerations, but every output is designed to be reviewed, challenged, and approved by qualified procurement professionals.
Three fundamental differences. First, the system is grounded in a knowledge graph of 12,400+ nodes of real GC procurement policy — it queries actual trade agreement thresholds and governance obligations rather than relying on training data. Second, it has deterministic policy gates that enforce compliance checks. Third, it produces structured outputs with inline source citations that trace every claim to a specific GC directive.
Plan procurements from vague intent. Generate SOWs with product-neutral requirements and policy citations. Build TBIPS professional services procurements with graph-sourced tasking and ceiling rates. Test sole-source justifications against GCR 6(d). Get policy guidance on trade agreements, security governance, PSIB, and accessibility. Research products and generate vendor-neutral requirements with comparables.
Procurement vehicles: SaaSSA, SLSA, TBIPS, NMSO, ProServices, and SSC Cloud Services. Trade agreements: CFTA, CETA, CPTPP, WTO-GPA. Governance: TRA, SA&A, PIA, GCEARB, PSIB, AIA. Compliance pillars: Security (Unclassified through Protected B), Privacy, Accessibility (WCAG 2.1 AA), and Official Languages. Plus sole-source exceptions under GCR 6(a)-(d) and value aggregation rules.
No. SOW requirements are built from actual product feature analysis — the system researches real product capabilities and translates them into vendor-neutral functional requirements. A SOW for Asana will have different requirements than a SOW for ServiceNow because they have different features.
Yes. The interface supports both official languages, and the system responds entirely in the user's language — using proper Quebec French procurement terminology, not machine translation.
The policy reasoning is grounded in a curated knowledge graph and produces consistently high-quality output. That said, it's not right 100% of the time. Every output includes source citations so you can verify claims, and the system is designed for professional review — not blind acceptance.
Contact
Ask a question about GC procurement or request a demo. Our system can provide a preliminary response.