How the Alpha sub-phase works
The official checkpoints of a digital service shows where Alpha comes in the whole journey, checkpoint by checkpoint.
You do not need a supplier, or developers, to start prototyping.
The cheapest prototypes need a pen, or half a day and an AI tool.
Before you start Alpha
THE MAKE-OR-BREAK QUESTION
Test the riskiest assumption first
Every idea rests on assumptions that, if wrong, sink the whole service: that people can and will use it, that it can connect to the systems it has to, that a legal or policy constraint can be met. Find the assumptions that would kill the service, and test those first. The killer is sometimes invisible in a demo: whether it can be made secure enough, fast enough under real load, or cheap enough to run. A prototype can test those too. Run the cheapest test that could prove each one false. An assumption that falls saves the cost of a wrong build, and that is a success. One that holds has earned the next test. Commit money to a build before the risky parts hold, and everything after it is at risk.
What to do in Alpha
The team you need
Alpha keeps Discovery's team and adds someone who can build. Keeping the same people holds the context and the momentum. The minimum roles (one person can hold more than one):
- User researcher plans and runs the testing.
- Designer shapes the prototypes and the journey.
- Developer or technologist builds the throwaway prototypes and probes feasibility.
- Business and policy lead knows the program, the rules, and the constraints.
- Business owner steers the work and owns the decision to go on, return, or stop.
In the Government of Canada the team is usually assembled from a mix of public servants and vendors. An alpha is short: roughly six to twelve weeks is typical.
CAUTION
When Alpha goes wrong
The prototypes get too polished and end up used as the real build.
Only the safe assumptions are tested, and the risky ones are avoided.
Prototypes are shown to stakeholders and never tested with real users.
The team commits to the build before the riskiest assumptions hold.
Alpha runs long and turns into a slow, expensive first version.
THE EXERCISE
How long it can be down is decided now
Two questions decide most of what the service has to be built to withstand. What could stop it or harm the people who use it, and how long it can be down before real harm starts. Both are worked out at the end of Alpha, while the design can still absorb the answer, and both feed the contract signed at the start of Beta.
Threats come in three kinds, and the Government of Canada's own guidance warns which ones teams forget:
- deliberate: theft, tampering, an insider, a coordinated attack
- accidental: human error, a contractor pulling the wrong cable, a software fault, mechanical or electrical damage
- natural: flood, fire, storm, earthquake, a pandemic
The RCMP's assessment guide puts it plainly: it can be easy to overlook natural and accidental threats with the greatest attention being paid to deliberate ones. Most teams picture an attacker and forget the flood.
Half a day with the right people in a room produces four things:
- the maximum allowable downtime (MAD): how long the service can be unavailable before a high degree of injury results
- the minimum service level: what counts as good enough during a disruption, which is often a manual or paper route rather than the digital service
- the recovery time objective (RTO): how fast it has to be back, which is a target set inside the maximum allowable downtime rather than the same number
- the recovery point objective (RPO): how much recent data can be lost, measured as time since the last usable copy
A four-hour maximum allowable downtime and a two-week one buy completely different architectures and completely different hosting bills. This is a spending decision made under a security-policy label, which is why it belongs here and not in a form filled in later.
There is one business continuity plan for the whole department. There is not a second one for this service. What the team hands over is the impact judgement, the four numbers, and the list of what this service falls over with, and it goes to the department's business continuity coordinator. What stays with the team is the recovery of this particular service and the testing that proves the recovery works.
This part is often misunderstood. The assessment is required for every service, with no threshold of any kind, but a standalone report is not: the guidance says producing one is neither recommended nor required, and nothing is submitted anywhere. What enforces it is the Authority to Operate, because without the assessment the person signing has nothing to accept.
Three instruments sit underneath this exercise: the harmonized Threat and Risk Assessment methodology for what could go wrong, the Standard on Security Categorization for how sensitive the information is, and Appendix D of the Directive on Security Management for how critical the service is and how long it can be down. Security explains how the assessment is done.
How you know Alpha is finished
Alpha is finished when you have a prototype substantial enough to decide, the riskiest assumptions have been tested, and you are confident you can build or buy something that meets the need and is cost-effective. What survives Alpha has earned the build.
The requirements are written and settled
Discovery handed over the problem, the people who have it, and what success would look like. Alpha turns that into what the service has to do.
The deadline is real, and it comes from the contract. The request for proposals is written from these requirements and goes out during Alpha, so they have to be settled early enough to publish. A requirement that is still vague on the day it is published stays vague in the contract, and changing it later costs a contract amendment.
Write them with the people who will use the service in the room. The Project Complexity and Risk Assessment (PCRA), the scoring tool that decides who is allowed to approve a project, asks directly whether the business requirements were validated with users, by walkthrough, workshop or independent review, and the answer moves the score. That question only reaches projects above a threshold, starting at $2.5 million for a department with no approved capacity class, so a small service never meets it and should do it anyway. Requirements written without users produce rework, and rework in Beta is paid for at contract rates.
The competition to find a supplier has begun
Only if buyingThe competition runs inside Alpha: the requirements are advertised, bids come in, and they are evaluated. It takes months, which is why it starts while the prototyping is still going on. The contract is signed at the start of Beta, when the competition ends, so Beta opens with a supplier already under contract and can begin building at once. A competition that has not started by the end of Alpha pushes that signature, and Beta waits.
A department building in-house, or reusing a platform that already exists, has no supplier to find and skips this entirely.
when the risky assumptions hold and you know the approach to build or buy.
when Alpha shows the problem was not understood well enough.
Stop,
when the evidence says it is not worth building. Stopping here still saves the cost of a wrong build.
The prototypes are archived; what they taught becomes the requirements. Have these ready before Beta starts:
- what the service has to do, written out so a builder can act on it
- the sharpened metrics that say whether it worked
- the accessibility clauses the service has to meet
- how the system has to behave: how fast, how available, and how long it holds records
- the data the service has to hold, and the metadata that describes it
- the recovery targets the exercise above produced: how long the service can be down, and how much recent data it can afford to lose
The official instruments in Alpha
Everything official that has something happening to it during Alpha, and what that something is. The tag says what stage the instrument reaches here, not that it is finished.
Placing an instrument in a sub-phase is this guide's own editorial choice, anchored where possible on a real deadline in the instrument itself. The full detail, including who does the work and what the business owner personally does, is in the table on the home page.
Every service
A rating of how much injury would result if the service's information leaked, if someone altered it, or if the service became unavailable.
The category is assigned. It decides the size of the control set the contract then has to buy, so a vague injury statement leaves that decision to someone else's estimate.
The exercise that lists what could go wrong, ranks each by how likely it is and how much damage it would do, and states the risk left over after safeguards.
First pass, against the design, while the design can still change. The service team supplies the security the business actually needs and the level of risk the department will carry.
- Security assessment and authorization, ending in the Authority to Operate (SA&A, ATO)AuthorizationSign or acceptsource
The formal permission for the service to run.
The authorizer approves the initial security assurance requirements, the control set, and the high-level design. Three of their seven approval points.
- Business impact analysis (BIA)AssessmentGather
The exercise that works out who is harmed if the service stops, how quickly that harm becomes serious, and what the service depends on.
Work out how long the service can be down before real harm starts, and how much data it can afford to lose. Those two numbers change the architecture and the hosting bill, so they belong before the build is bought.
Conformance of the service itself to the Canadian accessibility standard for information and communication technology, plus a published statement that names what does not conform, what the alternatives are, and when the gaps close.
Book the testing, and budget for the fixes it will find.
The department's own board, chaired by its chief information officer, that reviews a digital initiative's design against the government-wide architecture framework: look for something that already exists before buying or building, open standards, data, security and privacy.
The chosen direction is assessed. Arriving with the reuse scan from Discovery in hand makes it go quickly.
The written consent from Library and Archives Canada without which no government record may be destroyed, plus the department's own schedule saying how long each kind of record is kept.
Tell the information management office what records and data the service will create and hold, so they can map them to an existing authority or ask for a new one.
- Service in both official languagesStanding dutyGather
The duty to offer and deliver the service in English and French, equally and at the same time.
Design and test in both languages from the first prototype. Retrofitting French into an interface built around English is where the cost arises.
The decision about where the service runs, made against a government-wide preference order rather than a local preference.
Decide the hosting model while the design can still absorb the answer, and take it to the departmental board. Anything other than public cloud at Protected B or below also goes to the government-wide board.
- Access to information readiness, and the duty to documentStanding dutyGather
Everything the service records is subject to an access request, and decisions of business value have to be documented in the first place.
Say what decisions the service will make and what evidence it should keep, so the system is built to produce a retrievable record.
- Open data and open informationFilingCheck
The expectation that data and information of business value are released openly by default, in reusable formats, unless something specific stops it.
Work out what the service will hold that could be released, and what stops it. Editorial placement.
Only if it applies
- Physical security assessment and Authority to Occupy Facility (ATOF)AuthorizationCheck
The second, parallel security track, for buildings, equipment and physical space rather than systems.
Work out whether the service touches physical space at all. Editorial placement: the guide's own timing, chosen so the answer arrives before the solicitation.
Applies when: Only if the service touches physical space: new accommodation, hardware in people's hands, kiosks, or software that operates doors, gates, lighting or heating. A cloud-hosted service with no hardware usually stays clear of it.
A structured look at what personal information the service collects, why it is allowed to, where it flows, how long it is kept, and what happens to people if it goes wrong.
Hand over what the assessment is built from: what personal information the service will use, and which decisions about people it will be used to make.
Applies when: Triggers are broad. A new or substantially modified program that creates, collects, uses, discloses, retains or disposes of personal information brings it into scope. So does using it for an administrative purpose, contracting the program out or transferring it, bringing in a third party, changing the technology that processes it, or automating a decision. No dollar or user-count threshold.
A questionnaire the department fills in about itself, scoring how much an automated decision could affect people's rights, health, economic interests or the ongoing sustainability of an ecosystem.
Decide whether the service will automate a decision. Deciding this in Beta leaves no time to design the automation differently, and the only remaining option is to record the impact rather than reduce it.
Applies when: Only if the service makes or supports an automated decision about a person: scoring, ranking, recommending, or auto-approving. A later efficiency feature can trigger it without anyone noticing.
A supplier's written statement of how far their product meets the accessibility standard, clause by clause, with the gaps named.
Work out which clauses of the standard the service has to meet, so they go into the solicitation rather than being argued about later.
Applies when: Only when buying. An in-house build has no supplier and no report; the equivalent duty is the department's own conformance assessment against the standard.
The government-wide architecture board, co-chaired by the Chief Technology Officer of Canada and the Chief Technology Officer of Shared Services Canada, which reviews only the large or unusual initiatives.
Check every one of the six triggers, not only the dollar one. The non-dollar triggers catch small initiatives that assume they are too small to qualify.
Applies when: Any one of these is enough. The department is willing to invest $2.5 million with no class or class 1, $5 million at class 2, $10 million at class 3, $15 million for National Defence, $25 million at class 4. Or the initiative involves emerging technologies. Or it needs an exception under the directive. Or it is categorized at Protected B or below and uses a deployment model other than public cloud. Or it extends or creates custom support to stop a technology becoming unsupported. Or the Chief Information Officer of Canada directs it.
The formal request to the Treasury Board for authority and money when the project is beyond what the minister can approve alone.
Written and submitted. It takes months, and a gender-based analysis plus is required with it.
Applies when: When the project's complexity level exceeds the department's approved capacity class, or the department has no class and the project is over $2.5 million. Plus all programmes. Plus procurement or real property above their own approval limits.
- Official languages in what you buyStanding dutyGather
The obligation to write official languages requirements into the contract, so a supplier is contractually bound to deliver both languages rather than being asked for French later as a change request.
The requirement goes into the solicitation, alongside the accessibility clauses, before anyone bids.
Applies when: Whenever a supplier delivers, hosts or supports any part of a service that reaches the public, or produces content on the department's behalf. Guidance is set through a contracting policy notice.
- Security Requirements Check List (SRCL, form TBS/SCT 350-103)SubmissionFill
A short form that states, for one specific contract, exactly what security the supplier and its people need: what level of information they will touch, what screening each role needs, and whether the company may hold government information at its own offices.
Drafted while getting ready to buy, because the clauses it produces have to be in the solicitation.
Applies when: Only where the supplier or its people will access Protected or Classified information or assets, enter restricted sites, or connect electronically to departmental systems, which includes any access to personal information the department holds. Where there are no security requirements, no check list is produced and the department certifies that instead.
- Supplier organization and personnel security screeningAuthorizationCheck
The clearances a company and its individual staff must hold before touching sensitive government work.
Find out what clearance level the work needs, because it sets the timeline more than the procurement does.
Applies when: Every procurement whose Security Requirements Check List identifies a security requirement, and the same applies to subcontractors at every tier. Organization screening covers Protected A, B and C; a facility clearance is for Classified.
- Cloud security profile, guardrails, and the cloud authorizationAuthorizationCheckGather
The extra security work a cloud-hosted service carries: a ready-made control profile to build against, a set of guardrails to be in place within the first days of a new cloud environment, and a security assessment that has to account for what the cloud provider does versus what the department does.
Establish which control profile applies and what the provider covers, because it changes the size of what the department has to build and buy.
Applies when: Only for cloud-hosted services. The Protected B control profile is the usual starting point. The Cyber Centre separately assesses cloud service providers, so a department inherits that assessment rather than repeating it, and assesses only its own configuration and use.
- Identity and credential assurance levelsAssessmentGatherFill
Two ratings, from one to four, of how sure the service has to be about who someone is, and how strong the sign-in has to be.
The level is set. It decides whether the service can use a simple sign-in or needs strong authentication and identity proofing, which is not a late-stage change.
Applies when: Any service where people or businesses have accounts, sign in, or are identified. A worksheet under the authentication requirements guideline produces the level. At level three and above, multi-factor authentication follows.
- Government of Canada credential and sign-in servicesStanding dutyCheck
The shared sign-in services a department uses instead of building its own: the government-branded credential service, the commercial bank-based option, and the newer federated sign-in platform.
Pick the credential route before the prototype hard-codes a sign-in of its own.
Applies when: Any external-facing service where clients sign in. Onboarding to the federated platform involves a compliance attestation and testing in a client acceptance environment.
- Publishing under the canada.ca brandStanding dutyCheckGather
The rules for anything the public sees: the domain, the global header and footer, the Government of Canada signature and wordmark, the mandatory page templates, the information architecture, and the content style guide.
Bring the departmental web team and the head of communications in before the first prototype. The templates and the information architecture are usually discovered at Beta, when a custom-designed prototype meets the web team for the first time.
Applies when: Every external-facing website and web application. Two sign-offs: inside the department the head of communications is accountable for external-facing sites, and outside it the Principal Publisher, which is Employment and Social Development Canada through Service Canada, controls the canada.ca domain and must approve every domain and sub-domain.
- Mobile: responsive by default, native app by justificationStanding dutyCheck
The rule that a public-facing service works properly on a phone, and that building a downloadable app instead of a responsive web page has to be justified.
Decide responsive web against native app during prototyping, with evidence from user research, not after the build.
Applies when: Every public-facing website and web application.
Assumptions this page makes
You are already working to the Government of Canada Digital Standards, design with users, iterate and improve frequently, work in the open, use open standards, address security and privacy, build in accessibility, empower staff, be good data stewards, design ethical services, and collaborate widely, and to the law on privacy, security, official languages, and accessibility. The standards say how the government works in the digital world. The six Government of Canada digital competencies say what every public servant has to be able to do to work that way, and the team page covers them. This guide builds on those.