How the Alpha sub-phase works
Checkpoints a GC digital service has to pass 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
Find the assumptions that would kill the service, and test those first. 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.
Most services are not killed by their software. The usual killers:
- Policy does not allow it.
- Nobody has the legal authority to do it.
- The data the service depends on does not exist.
- The people it is for will not use this channel.
- Another department owns a step, and will not change it.
Most teams spend their Alpha the other way round, on the prototype, because the prototype is the part they can see and act on. That is the mismatch worth noticing. A technical answer of no can certainly end an idea, so none of this says skip the technical tests. It says the prototype is one reason among many, and the reasons above it are the easiest to miss, the slowest to fix, and usually settled by somebody outside the team.
Technical killers are real too, and Alpha can only take them so far. Alpha answers whether a thing is possible: can the system of record be connected to at all, is the data really there, will security ever accept this approach. Whether it is fast enough under real load, or cheap enough to run, is not knowable until Beta. Plan for those. Do not claim to have tested them.
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
What could take the service down, and how long it can stay down
Start with three questions about criticality
Criticality is how much harm follows if this service is unavailable, wrong, or breached. It is not a judgement about how important the work feels, and a large budget does not make a service critical. User numbers count only through the harm they carry: a service used by millions usually does more damage when it fails, and a service used by a few hundred can be just as critical if what it does for them is urgent. Sit down with the people who know what the service is for and answer three questions. What comes out of them decides which official obligations reach the service, how much protection its information needs, and how much engineering has to go underneath it.
| Question | What the answer decides |
|---|---|
| What duties attach to it? | A service the public can reach owes both official languages, the accessibility standard, and an authority to operate. An internal tool owes fewer of those. This one is about obligations, not importance. |
| What does it hold? | Nothing sensitive, or personal and financial information. The second answer brings a privacy assessment, a security categorisation, and rules about where the data may live. |
| What happens when it fails? | Inconvenience, or harm. This is the one that takes real work to answer, so the rest of this block is about it. |
What duties attach to it?
A service the public can reach owes both official languages, the accessibility standard, and an authority to operate. An internal tool owes fewer of those. This one is about obligations, not importance.
What does it hold?
Nothing sensitive, or personal and financial information. The second answer brings a privacy assessment, a security categorisation, and rules about where the data may live.
What happens when it fails?
Inconvenience, or harm. This is the one that takes real work to answer, so the rest of this block is about it.
Then give the third question half a day
Two answers do more than any others to set how much this service costs to run and how much engineering has to go underneath it. They are not the only inputs, but they are the ones most often left until it is too late to act on them. Get them wrong in one direction and you gold-plate a service nobody would miss for a fortnight. Get them wrong in the other and people are harmed within hours of an outage nobody planned for. Half a day with the right people settles both:
- What could stop the service, or harm the people who use it?
- How long can it be down before real harm starts?
Do it at the end of Alpha, while the design can still absorb the answers.
First, name what could go wrong
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.
Four numbers come out of that half-day: how long the service can be unavailable before real harm starts, what counts as good enough while it is down, how fast it has to be back, and how much recent data can be lost. Security defines each one and says who receives them.
Four hours and two weeks are not two settings of the same service. They buy different architectures and different hosting bills. So this is really a spending decision, even though it arrives wearing a security-policy label. Answer it here, with the people who know what the service is for. Leave it to a form somebody fills in later, and the budget gets set by whoever happens to be holding the form.
Then hand it over
The numbers do not stay with the team once they are set. They go to the department's business continuity coordinator, because the department keeps one continuity plan covering everything it runs. Security explains what is handed over and what the team keeps.
Doing the assessment is required for every service, at any size, with no threshold. Writing it up as a report is not. The guidance says a standalone report is neither recommended nor required, and there is nowhere to submit one, so nothing will chase you for it. What makes it real is the Authority to Operate at the end of Beta. The person who signs that is accepting the risk, and without the assessment there is nothing for them to accept.
Three instruments sit underneath the half-day: 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, written so somebody else could build it.
Settled means settled, because the request for proposals is written from them and goes out during Alpha. A requirement still vague on the day it is published stays vague in the contract, and changing it after that costs an amendment.
The competition to find a supplier has begun
Only if buyingAdvertising the requirements, taking bids and evaluating them runs into months, which is why it starts while the prototyping is still going on rather than after it.
Whether Alpha ends with a contract signed or with one still to sign depends on the route, and both are normal. What is not survivable is a competition that has not started by the time Alpha closes, because then Beta simply waits.
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.
Whatever the team made is either archived or carried into Beta, depending on how it was built, and what all of it taught becomes the requirements either way. 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 full instruments table.
- Check
- Find out whether it applies to this service at all.
- Gather
- Hand over the business judgement only the service team holds. Someone else writes it up.
- Fill
- The thing is actually produced.
- Sign or accept
- A named person puts their name to it, or receives someone else's result and decides what to do about it.
- Submit
- Sent, filed, registered or published where the rule says.
What the tags mean
Every service
A rating of how much injury would follow a leak, an unwanted change to the information, or an outage.
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 one by how likely it is and how much damage it would do, and states the risk left over once the safeguards are in place.
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 in production.
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 decides how critical the service is, and produces four numbers with it: maximum allowable downtime, minimum service level, recovery time objective and recovery point objective.
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, which 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.
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.
A set of things any system holding government information has to be able to do: apply retention and disposition rules in a way that can be audited, carry metadata, support the department's classification structures, work with other systems, and export in bulk in open formats.
These become requirements here, while the solicitation is still being written.
- Service in both official languagesStanding dutyGather
The duty to offer and deliver the service in English and French at the same time and to the same standard.
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: software as a service before platform before infrastructure, and public cloud before hybrid before private before non-cloud.
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 can be asked for under 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 security track, running in parallel and covering buildings, equipment and physical space.
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 could happen 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 scored questionnaire about how much an automated decision could affect a person's rights, health or 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.
- Official languages in what you buyStanding dutyGather
The obligation to write official languages requirements into the contract, so the supplier is contractually bound to deliver both languages.
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.
A short form that states, for one 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.
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.
A government-wide commitment that at least 5% of the total value of contracts goes to Indigenous businesses each year.
Say whether the work could be done by an Indigenous business while the solicitation is still being written. Once it is published the route is fixed.
Applies when Only when buying. The target belongs to the department and not to any one contract, so no single procurement has to be set aside. Every procurement is where the target is met or missed, which is why departments plan for it up front. Whether a supplier counts is verified through Indigenous Services Canada.
The extra security work a cloud-hosted service carries: a ready-made control profile to build against, guardrails that have to be implemented, validated and reported within the first 30 business days of getting a cloud account, and a security assessment that accounts for the split between what the provider does and 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.
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. There are four levels, one to four, running from little confidence needed to very high confidence needed. A worksheet in the Guideline on Defining Authentication Requirements produces the level for a given service.
- Government of Canada credential and sign-in servicesStanding dutyCheck
The shared sign-in services a department can use in place 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. Joining a shared platform involves compliance checks and testing before go-live, and the platform's own team sets what those are.
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. Inside the department the head of communications is accountable for external-facing websites and for mobile applications, and the directive holds both to its Appendix D, the Standard on External-facing Websites and Mobile Applications. The same directive requires the official web analytics tool administered by Service Canada.
- Responsive web, or a native mobile appStanding dutyCheck
The rule that a public-facing service works properly on a phone, and that choosing a downloadable app over 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.
The government-wide architecture board, co-chaired by the Chief Technology Officer of Canada and the Chief Technology Officer of Shared Services Canada.
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 above 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 above 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.
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.