Owen Sound: A Four-Year City Business Plan

Home › Information, Privacy and Canadian Digital Independence › Chapter 33

Information, Privacy and Canadian Digital Independence

Chapter 33map.ca as Public Infrastructure

12,556 words · Mike Seiler · Owen Sound, Ontario

Open in the reader →

Vote on the proposals, hear the audio, read the reviews, search the whole plan.

In this chapter

The original proposal is deliberately ambitious.

It says:

Those ideas share one principle:

Some digital systems are becoming important enough to civic life that the public should not be permanently dependent upon advertising platforms, political organizations or private founders to access them.

But there is an equally important principle:

A good public-purpose idea does not justify a bad public transaction.

I have a relationship with map.ca and the related ideas being proposed.

That makes the governance question more important, not less.

The City should never be asked to:

adopt Mike's platform because Mike became Mayor.

The correct sequence is:

  1. define the public problem;
  2. define the open public standard;
  3. establish the legal and governance requirements;
  4. disclose every relevant private interest;
  5. independently assess the platform;
  6. compare alternatives;
  7. allow Council and professional staff to decide;
  8. proceed only if the public case survives without the founder's influence.

The RealMap working paper already recommends this approach. It identifies a municipal open standard as the preferred first step, with an independent public-interest nonprofit considered only if a transfer proves lawful, affordable and free of private advantage. Direct municipal ownership is specifically identified as the highest-burden option rather than the recommended starting point.

That should become the map.ca rule too.

Public standard first. Platform second. Founder last.

33.1What "Public Infrastructure" Means

Calling something public infrastructure should mean more than:

The public uses it.

Millions of people use private platforms every day.

Public infrastructure should satisfy a stronger test.

It should provide a defined public benefit while protecting:

Most importantly:

The public purpose should survive the company, the technology and the person who first built it.

33.2The Public Infrastructure Test

Before map.ca can be described by the City as public infrastructure, it should pass at least these questions.

Purpose

What public problem does it solve?

Access

Who can use it?

Cost

What is free and what is paid?

Governance

Who controls the rules?

Data

Who controls information?

Privacy

What is collected?

Neutrality

Can political or commercial influence alter visibility?

Portability

Can information move elsewhere?

Accessibility

Can people with disabilities use it?

Resilience

What happens if systems fail?

Finance

Who pays over the long term?

Exit

Can Owen Sound stop using it?

If those questions have weak answers:

It is not ready to be civic infrastructure.

33.3"Protected Public Ownership" Needs a Definition

The original proposal says map.ca should move into protected public ownership before municipal adoption.

That phrase expresses an objective.

It is not, by itself, a legal structure.

Before it appears in a final Council proposal, legal and governance professionals need to determine what structure can actually achieve the intended protections.

Possible models include:

The name of the legal structure matters less than whether the public protections actually work.

33.4Open Standard First

My preferred municipal starting point is:

Owen Sound defines the standard, not the platform.

The City can establish requirements for public-interest civic information such as:

Then map.ca or another qualifying system may be evaluated against that standard.

That prevents the public policy from being written around one private product.

33.5map.ca Must Be Allowed to Fail the Test

This is one of the most important safeguards in the entire business plan.

Council must retain the ability to conclude:

The public-purpose concept is good, but map.ca is not the right implementation.

If that conclusion is impossible politically or contractually:

The evaluation was never independent.

33.6No Predetermined Municipal Adoption

A campaign can demonstrate map.ca privately.

It can:

It should not be represented before Council approval as:

Owen Sound's future official platform.

The accurate wording is:

A privately or independently developed public-interest platform being proposed for future evaluation.

33.7The City Should Not Start by Buying map.ca

The first Council motion should not be:

Purchase map.ca.

It should be closer to:

Define Owen Sound's public digital-information requirements and determine whether there is a municipal role.

The product follows the policy.

Not the reverse.

33.8Inventory What Actually Exists

Before discussing transfer, independently document what "map.ca" means.

Potential assets may include:

Do not negotiate a transfer of a brand name without knowing what is underneath it.

33.9Transfer Only What the Public Needs

A public transition does not necessarily require transferring every related:

Determine the minimum assets required for the public purpose.

Everything else can remain:

depending upon the eventual structure.

This reduces unnecessary public liability.

33.10Domain Ownership Matters

For a map-based public infrastructure platform, the domain itself is a significant asset.

If transferred into a public-interest structure:

should no longer depend upon one individual's personal account.

A public domain should be institutionally controlled.

33.11Intellectual Property Must Be Clear

Before public adoption, establish:

A domain transfer without the necessary operating rights may produce little public value.

A software transfer without the necessary domain rights may create a different problem.

Understand the complete package.

33.12Independent Valuation

Any proposed:

of map.ca-related assets should receive independent valuation.

The RealMap working paper already requires arm's-length valuation of any asset, licence, service or transfer and calls for ownership and financial relationships to be disclosed.

Valuation does not mean the City should pay the appraised amount.

It means the public should understand what is being transferred.

33.13A One-Dollar Transfer Is Still a Transaction

If a founder says:

I will give this to the public for one dollar,

that may be generous.

It still requires examination of:

The purchase price is not the complete cost.

33.14A Donation Can Still Create a Conflict

Giving something away does not automatically eliminate a conflict.

A public transfer might still:

Those effects need to be considered independently.

33.15Municipal Assistance to Private Business

Ontario's Municipal Act contains specific restrictions dealing with municipal assistance to manufacturing, business and commercial enterprises, along with statutory provisions governing when assistance may be authorized. Any arrangement in which the City provides money, property, free commercial services or another economic advantage to map.ca or businesses using it therefore requires proper municipal legal review rather than an assumption that a good economic-development purpose automatically makes the arrangement lawful.

That same caution applies to:

Design the public benefit within the law.

Ontario's Municipal Conflict of Interest Act addresses both direct and indirect pecuniary interests and restricts the use of office to influence matters where the statutory conflict rules apply.

Therefore, if map.ca comes before Council while I retain a relevant financial interest, I should not invent my own interpretation of whether I may participate.

The process should involve:

33.17The Higher Political Standard

Even where the strict legal conflict rules do not apply to some particular aspect, I would use a broader public-trust test:

Would a reasonable resident think I may personally benefit from this decision?

If yes:

Remove the Mayor from:

Public confidence matters alongside minimum legal compliance.

33.18No Strong-Mayor Shortcut

No special mayoral authority should be used to force municipal adoption of a platform connected to the Mayor.

Even if a power could theoretically be engaged in some future circumstance:

The conflict and public-trust problem should prevent that path.

The platform should succeed through:

Not mayoral power.

33.19No Founder Procurement Design

The person associated with the proposed platform should not write a tender whose technical requirements conveniently describe only their own product.

Independent municipal professionals should define:

If map.ca genuinely meets those requirements:

It can be assessed properly.

33.20No Founder Valuation

Likewise, the founder does not decide:

This platform is worth $X.

Independent professionals determine valuation using appropriate methods.

The founder can provide:

Not the final public conclusion.

33.21No Founder Veto

If map.ca ultimately becomes genuine public infrastructure:

I should lose the ability to veto what the public institution does with it.

The public owner or governing body must be able to:

according to its lawful governance.

A public asset cannot remain privately controlled because its creator has strong opinions.

33.22Founder Transition Period

A limited transition role may be useful if the founder possesses important technical or institutional knowledge.

That role should have:

The objective should be:

Make the founder unnecessary to routine operation.

That is successful institutionalization.

33.23No Perpetual Royalty

A public-interest transfer should avoid creating a permanent private royalty tied to:

unless an extraordinary independently reviewed case demonstrates why that arrangement serves public value.

The cleaner model is public ownership or clearly limited rights without a perpetual personal tollbooth.

If public map.ca depends upon a private company related to its founder for:

those relationships must receive the same scrutiny as any other vendor.

The public transfer should not simply move the visible asset while leaving every meaningful operating contract inside a related private company.

33.25Governance Model A: Remain Private

map.ca could simply remain private.

In that model:

That remains a legitimate outcome.

Public-interest ambition does not require government adoption.

33.26Governance Model B: Independent Public-Interest Nonprofit

Another option is moving defined assets into an independent organization with:

The existing RealMap governance paper identifies this as one possible structure, but only with valuation, independent appointments, transfer terms and founder-interest controls.

This model deserves serious study.

It should not be assumed automatically lawful or sufficient.

33.27Governance Model C: Municipal Open Standard

The strongest first municipal model may simply be:

The City publishes the rules for civic information and allows qualifying platforms to interoperate.

The existing RealMap work identifies this model as having lower monopoly risk while preserving choice and interoperability.

This allows map.ca to prove itself without forcing Council to own the technology.

33.28Governance Model D: Municipal Ownership

Direct City ownership could provide maximum formal municipal accountability.

It would also bring responsibility for:

The RealMap working paper identifies direct municipal operation as carrying the highest staffing, privacy, cybersecurity and market-displacement burden and does not recommend it as the first step.

I agree.

The four-year sequence should therefore be:

First

Define the public standard.

Second

Test map.ca independently.

Third

Consider an independent public-interest ownership structure if justified.

Fourth

Allow municipalities to integrate through open standards.

Fifth

Consider deeper municipal ownership only if evidence eventually establishes a compelling reason.

Do not leap directly from campaign prototype to City-owned technology.

33.30Public-Interest Board

If an independent organization ultimately holds public assets, its board should not become:

Potential competencies could include:

The exact appointment model requires legal design.

The principle is independence.

33.31No Permanent Founder Majority

The creator of the platform may be useful during transition.

The founder should not hold permanent majority control over a public-interest board.

Otherwise:

The ownership changed on paper.

The control did not.

33.32No Permanent City Political Majority Either

If the platform eventually serves multiple communities, it may also be inappropriate for one Council to control every future decision.

A national or multi-municipal public-interest platform requires governance that can outlive:

Owen Sound can be a proving ground without becoming permanent ruler of the network.

33.33Participating Municipalities

If other municipalities eventually choose to use the system, their role should be defined.

Possible mechanisms may include:

Do not design a national governance structure before one municipality proves the concept.

Scale governance with actual adoption.

33.34The Public Mission

Any public-interest operator should have a simple mission.

For example:

Make useful place-based civic and community information easy to discover, portable and accessible without selling attention or personal behaviour.

The mission should constrain the organization.

It should not be broad enough to justify entering every imaginable technology business.

33.35Mission Protection

If assets are transferred at below-market value for a public purpose, the transfer should examine how that purpose remains protected if the organization later:

Possible legal mechanisms depend on the final organizational structure.

The principle is:

Public assets should not quietly become private windfalls later.

33.36Dissolution

Before creating an organization, decide what happens if it closes.

Questions include:

Dissolution planning is part of creation.

33.37Public Annual Report

A public-interest map.ca organization should publish an annual report covering at minimum:

Public infrastructure requires public accountability.

33.38Independent Financial Review

The scale of financial review should grow with the organization.

At minimum:

A public organization should not rely on:

Trust us.

If board members or founders have businesses contracting with the platform, disclose and govern those relationships.

The register should identify:

Related-party dealings may sometimes be legitimate.

Hidden related-party dealings are the problem.

33.40Campaign Firewall

No campaign:

should transfer into map.ca's civic infrastructure.

Likewise, map.ca public-service data should never transfer to a campaign.

Two Worlds

Campaign

and

public service

must remain technically and legally separate.

33.41No Incumbent Advantage

A future Mayor should not be able to send:

A message from the Mayor

through resident accounts for electoral advantage.

Official municipal communications need:

The platform must serve the institution.

Not the incumbent.

33.42Public Branding

If map.ca becomes independent public infrastructure, branding should make the governance status understandable.

Residents should be able to tell:

Is this the City?

Is this an independent public-interest organization?

Is this a private company?

Is this a community-submitted page?

Do not intentionally blur institutional identity.

33.43Basic Browsing Without an Account

Most public information should be viewable without:

A person looking for:

does not need to identify themselves.

Anonymous Where Anonymous Works

Verification only where verification is needed.

33.44Optional Civic Account

An account may be useful for:

Account creation should remain voluntary for basic browsing.

No account should become a condition of ordinary citizenship.

33.45The "Email for Life" Proposal

The source proposal promises every resident an email for life.

I would keep the ambition.

I would change the certainty.

A City should not promise an electronic service literally forever before establishing:

The final public promise should be:

Develop a permanent, portable civic contact address designed to remain with the resident long term, and make any lifetime commitment only when the governance can genuinely support it.

33.46Civic Address Rather Than Giant Mailbox

The first model worth testing may be a civic email alias rather than a full municipal mailbox.

For example, the service could potentially provide a stable address that forwards to an email account chosen by the resident.

Advantages may include:

The technical design requires professional review.

The principle is:

Own the address without requiring government to store your entire correspondence.

33.47Not Government Identification

A map.ca email address should not automatically prove:

It is a communications tool.

Nothing more unless a separate lawful verification system is deliberately created.

33.48Do Not Put Voting Inside the Email Account

VoteMap or other civic consultation systems should not rely solely upon possession of a map.ca email address as proof of voting eligibility.

Verification for:

must follow the requirements appropriate to each process.

Convenience should not weaken democratic integrity.

33.49Portability When Someone Moves

The original vision extends beyond one town.

A civic address intended to move with someone should not cease simply because they move from:

That is another reason a long-term civic identity may belong better in an independent public-interest structure than inside one municipal IT department.

33.50No Forced Portability Claim

Until other communities or a broader governing organization agree:

Owen Sound cannot promise:

Every Canadian municipality will recognize this address.

We can build the standard.

We can invite participation.

We cannot legislate another municipality's system.

33.51Account Recovery

A lifetime-oriented account creates a serious recovery problem.

People:

Design recovery carefully.

Avoid using unnecessarily sensitive identity information merely because account recovery is difficult.

33.52Death and Digital Legacy

Long-lived accounts need a policy for:

Do not leave families guessing what happens.

Digital infrastructure eventually encounters ordinary human life.

33.53Minors

Do not automatically create lifelong digital accounts for every child without carefully considering:

YouthMap should work without requiring children to build permanent public profiles.

33.54Email Abuse

A civic email system could be abused for:

Terms and enforcement need to address actual abuse while preserving legitimate communication.

A permanent address does not mean permanent immunity from rules.

33.55Account Suspension

If an account is restricted:

Provide an appropriate:

Permanent civic infrastructure should not allow arbitrary account removal based on political disagreement.

33.56Do Not Promise a "Safe Email"

No email provider can guarantee that residents will never receive:

The platform can provide:

Do not market technology as eliminating human deception.

33.57Separate Identity From Behaviour

A civic account should not silently become the key connecting:

That level of integration may be convenient for software.

It is dangerous for civic privacy.

33.58One Door Does Not Mean One Giant Profile

map.ca can provide one public doorway without building one universal resident dossier.

Behind the interface, information should remain separated according to:

Convenient Interface

Separate Data Responsibilities

Both are possible.

33.59No Civic Social Score

Never create a resident score based on:

There should be no:

good citizen score.

Public participation is voluntary.

Rights are not earned through platform activity.

33.60Public Map, Not People Map

The central map should primarily map:

It should not publicly map:

Map the opportunity. Protect the person.

33.61Public Infrastructure Layers

Possible verified public layers could include:

Each layer should identify:

33.62Sensitive Infrastructure Layer

Not every municipal asset belongs on the public map.

Detailed information concerning:

may need to remain internal.

The public version can show what residents need without publishing information that creates unnecessary risk.

33.63Official, Partner and Community Information

Every map entry should make source type understandable.

Possible categories:

Official

Published or validated by the responsible public authority.

Partner

Maintained by an identified participating organization.

Community

Submitted by a user and not necessarily officially verified.

This reduces the temptation to make every item look equally authoritative.

33.64Verification Must Mean Something Specific

A "verified" badge should explain:

What was verified?

Possibilities include:

Do not use one blue check mark to imply everything about an organization is trustworthy.

33.65Last Verified Date

Place-based information changes.

Every significant public listing should show:

A resident should be able to distinguish:

confirmed yesterday

from

submitted five years ago.

33.66Community Correction

Users should be able to report:

A report triggers review.

It does not automatically rewrite official information.

33.67Correction History

For important official public assets, maintain enough history to understand:

Do not create permanent public records of every spelling correction.

Use judgement.

33.68Disputes

A platform mapping:

will create disputes.

There should be procedures for:

The platform should not attempt to decide complex legal disputes beyond its authority.

Refer matters appropriately.

33.69Viewpoint-Neutral Moderation

Community information may include organizations with:

views.

Moderation should focus on defined issues such as:

Do not remove lawful community organizations merely because platform administrators disagree with them.

33.70Community Calendar

The original plan calls for:

every event, activity and opportunity in one safe place, free to list, free to browse, no advertising, no tracking.

That should become one of the first public-interest features.

The word safe should mean:

It should not mean the City guarantees the physical safety of every third-party event.

33.71Calendar Categories

Possible categories include:

Users decide what they want to see.

The platform should not algorithmically decide which community activities deserve attention.

33.72No Paid Calendar Ranking

A large organization should not appear above a small neighbourhood activity because it paid more.

Sort by transparent factors such as:

Visibility is not for sale.

33.73Political Events

If lawful public event listings meet neutral calendar rules, political events should not be excluded simply because they are political.

The listing should clearly identify:

The City hosting a neutral calendar does not endorse the event.

33.74Faith Events

The same applies to:

Equal listing rules.

No religious preference.

No anti-religious exclusion.

33.75Commercial Events

Businesses may also host legitimate public events.

The platform should define whether and how they qualify.

Do not force every commercial event into:

A public calendar is useful partly because it shows what is actually happening.

33.76RealMap.ca

RealMap should remain a distinct vertical within the broader system.

Its public-interest standard was established in Section 25:

The City should be able to adopt those standards without adopting the RealMap platform.

33.77RealMap Data Must Stay Separate

A resident looking at:

homes between $450,000 and $550,000

should not automatically alter:

Property search is sensitive behavioural information.

Keep it separated.

33.78YouthMap.ca

The original plan calls for YouthMap.ca to map youth opportunities across Grey Bruce and beyond.

The Civic Corps principle applies:

Map opportunities. Not youth.

YouthMap may list:

It should not publicly list individual young people.

33.79Opportunity Verification

Youth opportunities should identify:

The map does not guarantee:

Organizations remain responsible for their programs.

33.80Youth Privacy

A young person should not need to publish:

to browse opportunities.

Applications occur through the responsible organization.

The map remains an information layer.

33.81Shop Local

map.ca may also connect with the Shop Local strategy.

Residents could find:

Basic public discovery should remain separate from paid placement.

A business with a small marketing budget should not disappear from the map.

33.82Local Ownership Labels

Where business information identifies:

the criteria should be factual and published.

Do not make assumptions based on a brand name.

Businesses should be able to correct classification.

33.83Public Business Information and Municipal Assistance

If the City itself funds or provides free services to commercial enterprises through map.ca, municipal legal review is required because Ontario law contains specific rules concerning assistance to business and commercial enterprises.

That means we should separate:

Do not casually blend them.

33.84Paid Features

A future public-interest operator might offer paid optional services.

If so:

Paid features should never purchase superior placement within the basic public information layer.

Possible paid services might involve:

The public core remains neutral.

33.85No Transaction Commission

map.ca public infrastructure should not need to take a percentage every time residents:

Where possible, transactions remain directly between:

The infrastructure helps people find each other.

It does not need to own the transaction.

33.86No Lead Selling

A resident searching:

plumber

should not become a lead auctioned to several plumbers.

A person looking for information should receive information.

If they explicitly ask businesses to contact them:

That is a different service and needs clear consent.

33.87No Advertising

The original calendar proposal explicitly commits to no advertising and no tracking.

I would extend that philosophy to the core public map.

Basic Civic Layer

No:

If commercial features exist elsewhere:

Keep them visibly separate from the public infrastructure.

33.88No Behavioural Tracking

The system should not build profiles such as:

This resident attends these churches, searches these homes, visits these businesses and looks at these political events.

That is exactly the kind of information concentration a public system should avoid.

Measure the platform without profiling the resident.

33.89Minimal Analytics

Useful operating analytics may include:

Where possible, obtain those measures without maintaining long-lived individual behavioural histories.

The question is:

Does the service work?

Not:

Who is this person and what else can we infer about them?

33.90No Sale of Data

The public-interest operator should not fund itself through sale of:

If a future proposal changes that rule:

It should require an explicit public governance decision.

Not a quiet terms-of-service update.

33.91Municipal Privacy Law

Municipal information systems are subject to Ontario's municipal privacy framework. MFIPPA limits collection of personal information on behalf of a municipal institution to circumstances authorized by law, used for law enforcement, or necessary to properly administer a lawfully authorized activity.

That provides a useful design question:

Why do we need this information?

If the public service works without it:

Do not collect it.

33.92Operator Roles Must Be Legally Mapped

If map.ca is operated by:

the privacy roles may differ.

Before launch, document:

Do not assume an arm's-length structure automatically solves privacy obligations.

33.93Separate Municipal Records From User Content

Different information may have different status.

Examples:

Municipal Record

A service request submitted to City Hall.

Public Contribution

A resident updates a public trail note.

Private User Content

A saved personal list.

The platform should know the difference.

Retention and access should follow the purpose and applicable law.

33.94Resident Content Rights

Terms should explain what happens when a resident contributes:

The platform may need a licence to display the material.

That does not necessarily require taking unrestricted ownership forever.

Use understandable terms.

33.95Delete What Can Be Deleted

Where information is not required as:

users should have reasonable control to remove their private platform content.

Explain exceptions.

Do not advertise:

Delete means deleted

if backups or legal retention prevent immediate complete destruction.

33.96Accessibility Is Mandatory Design Work

If map.ca becomes a municipal public website or web service, Ontario accessibility rules applying to designated public-sector websites need to be built into the implementation. Ontario's current Integrated Accessibility Standards require designated public-sector organizations' internet websites and web content to conform to WCAG 2.0 Level AA according to the regulation.

Accessibility should therefore be tested before adoption.

Not added after complaints.

33.97Accessibility Testing

Use both:

Include people who use:

A software report saying:

98 per cent accessible

does not tell us whether a real person can complete the task.

33.98Map Accessibility

Maps create particular accessibility challenges.

Important information should also be available through:

A resident who cannot visually interpret a map should not be excluded from the information represented on it.

33.99Objective Accessibility Information

For public places, map objective features such as:

Avoid broad promises such as:

Completely accessible

unless an appropriate authority actually supports that conclusion.

Describe.

Do not over-certify.

33.100Paper and Telephone Access

map.ca should improve public information.

It should not eliminate:

A resident can call City Hall and ask:

Where is the nearest accessible washroom?

Staff should be able to use the same public information system to answer.

The technology serves both sides of the conversation.

33.101Public Terminals

Where useful, existing public computers at:

can provide access for residents without their own devices.

Do not build a network of specialized map.ca kiosks before demonstrating demand.

Use what already exists.

33.102First to Action

map.ca could eventually become one visual doorway into the First to Action service system.

A resident might mark:

The important part is not the pin.

The important part is what happens afterwards:

  1. report enters the official service system;
  2. correct department receives it;
  3. status is tracked;
  4. resident receives closure where appropriate.

Do not build a public reporting map disconnected from actual operations.

33.103Public Report Versus Private Service File

A resident may publicly report:

Streetlight out here.

The City's internal service file may contain:

Those are not necessarily the same public dataset.

The interface should separate:

33.104No Public Map of Complainants

A public issue map should not say:

Mike Seiler reported this pothole from this home address.

The issue matters.

The complainant usually does not.

33.105Infrastructure Index

The Infrastructure and Systems Index could feed appropriate public map layers.

A resident could see:

Sensitive engineering and security information remains protected.

Map the public understanding layer.

Not the entire internal engineering system.

33.106River Spine

The River Spine can become one of map.ca's strongest public applications.

Possible information:

That turns the geography of Sections 18 and 19 into something residents can explore directly.

33.107Owen Sound Outside

An activity such as:

I want to try paddling

could show:

The map organizes the ecosystem.

It does not need to operate every activity.

33.108Community Partners

Community organizations should be able to maintain appropriate public information about:

They remain responsible for the service.

The map makes it discoverable.

33.109Emergency Information

During emergencies, map.ca could display safe public information such as:

Emergency information must come from the responsible authority.

Community users should not be able to mark:

Official emergency shelter

because they heard a rumour.

33.110One Official Source

map.ca should not create a competing emergency information authority.

It should display or connect to the official record.

One Official Source

Many Useful Interfaces

That principle survives the platform.

33.111No Vulnerability Map

Do not publicly map:

Map:

Protect vulnerabilities.

33.112Local Knowledge

Residents may contribute:

Where information becomes official municipal information:

Staff or appropriate professionals validate it.

Community Contributes

Authority Verifies

That remains the model.

33.113Indigenous Knowledge

Saugeen Ojibway Nation knowledge should never be treated as free municipal data simply because map.ca can store it.

Any use involving:

should occur through an appropriate relationship, consent and agreed governance.

The map does not own the knowledge it displays.

33.114Official Naming

Where public places have official names, the map should use the authoritative name.

Alternative:

names can be displayed appropriately when supported and respectful.

Do not allow map popularity to rewrite official geography accidentally.

33.115Search Neutrality

Public search results should rely upon published criteria.

Potential factors:

Do not secretly boost:

Search should be predictable enough to audit.

33.116No Personalized Civic Reality

Commercial platforms often show different users different feeds.

A public civic map should be much more cautious.

Two residents asking:

Where is the nearest public washroom?

should not receive different answers because of inferred behavioural profiles.

Personalization can be user-controlled.

Public facts should remain public facts.

33.117User Filters

Residents can still choose:

That is different from the platform secretly deciding what the person should see.

User Preference

Good.

Hidden Behavioural Manipulation

Avoid.

33.118Artificial Intelligence

AI may help map.ca with:

It should not become an invisible authority deciding what the community is.

Use AI as an assistant.

Keep:

33.119AI-Generated Information Should Be Identifiable

If AI generates:

make that clear where accuracy matters.

A machine-generated summary should not silently replace the official municipal source.

33.120No Private Resident Data for AI Training by Default

Resident:

should not automatically become training material for unrelated commercial AI models.

Any use of protected information requires proper authority and governance.

Public contribution and private behaviour are different.

33.121Public Data for Public Innovation

Safe open public datasets may be reusable by:

Possible examples include:

Publish documentation so people understand:

Open data without context can produce bad conclusions.

33.122Open Interfaces

Where appropriate, map.ca should provide documented ways for other systems to:

approved public information.

This allows:

to interoperate.

The public map becomes infrastructure rather than a closed website.

33.123No API Monopoly

If a public API exists, access rules should be:

Do not grant one company exclusive access to public data because it has a relationship with the founder.

33.124Rate Limits and Abuse

Open access does not mean unlimited abuse.

Interfaces may need:

Protect the service while keeping legitimate reuse possible.

33.125Open Source Where Practical

Parts of the public infrastructure may be suitable for open-source release.

Benefits can include:

Not every dependency or security configuration should be public.

The objective is maximum practical openness without compromising:

33.126The Open Playbook Matters Even if the Code Is Closed

Even if some software cannot legally or practically be open-source, Owen Sound can still publish:

Another municipality should be able to learn from us without buying from us.

33.127Canadian Hosting

The Digital Sovereignty principles from Section 32 apply directly.

For significant public information:

Canadian hosting may be preferred where it materially improves public control and risk.

It should still be evaluated on:

33.128The map.ca Domain Should Outlive Vendors

Hosting providers can change.

Developers can change.

AI providers can change.

The public:

should remain.

The architecture should allow replacement underneath a stable public service.

33.129Backups

Important public information needs independent backup.

Test:

A backup controlled by the same account that controls every live system may not provide enough resilience.

Technical professionals determine the correct architecture.

33.130DNS and Administrative Control

For a public-interest map.ca, administrative control over:

should use institutional security.

Not:

The founder has the password.

That is a single-person failure point.

33.131Cybersecurity

Before municipal integration, require professional cybersecurity review covering appropriate areas such as:

Do not publish the details that would make attack easier.

Publish that governance occurred.

33.132Security Incidents

If map.ca experiences a significant incident involving public information:

The responsible operator should follow:

Do not bury an incident because the platform's reputation matters.

Public trust requires truthful response to failure.

33.133Business Continuity

Ask:

If map.ca is offline for three days, what stops working?

A community calendar outage is inconvenient.

A critical municipal emergency function would be more serious.

Do not place essential services on the platform until appropriate continuity exists.

33.134map.ca Should Not Become the Only Door

Even if highly successful:

Residents should still be able to access essential municipal services through:

Redundancy protects both accessibility and sovereignty.

33.135Funding the Public Core

Public infrastructure still costs money.

Potential costs include:

Before transfer:

Publish the complete operating model.

33.136Free Does Not Mean Unfunded

The original proposal includes several free public functions.

If residents pay nothing at the point of use:

Somebody still pays.

Possible lawful funding sources could include:

Every source creates trade-offs.

Publish them.

33.137What Must Remain Free

Under this plan, I would protect free access to the basic public-interest layer.

That includes:

RealMap's free basic listing standard remains subject to the legal and governance review established in Section 25.

33.138No Paywall on Civic Facts

A resident should not have to subscribe to learn:

If the City funds or adopts the public layer:

Basic civic information remains public.

33.139Commercial Software Can Be Separate

An independent operator may eventually develop optional tools beyond the public infrastructure.

Possible examples might include:

Those should be financially and visually separated from the civic core.

Public ownership should not become an excuse for government to enter every software market.

33.140No Hidden Cross-Subsidy

If a commercial service loses money and the public infrastructure pays the bill:

Show it.

If commercial revenue supports the public layer:

Show that too.

Separate accounting protects both sides.

33.141Sponsorship

A sponsor could potentially help fund:

Sponsorship should never buy:

Recognition can be appropriate.

Influence is different.

33.142Donations

Private philanthropy could help build public infrastructure.

Any substantial donation should disclose:

A donation should not purchase permanent power over the platform.

33.143Grants

Government grants may help fund:

Do not build a permanent system whose operating model works only if the same temporary grant returns every year.

Grant Question

Who pays after the grant?

33.144No Municipal Debt Guarantee for an Experimental Platform

The City should not guarantee substantial private or nonprofit platform debt simply because it supports the idea.

Any future financing arrangement must pass the normal:

tests.

Digital enthusiasm is not a substitute for solvency.

33.145Cost Per Resident

If municipal funding is eventually proposed, show the practical cost.

For example:

Annual municipal contribution

divided by

residents served

can provide one perspective.

It should not be the only measure.

But residents deserve to understand scale.

33.146Cost Per Service

Also understand major feature costs.

How much does it cost to operate:

A feature should not hide behind the total platform budget.

33.147No Vanity Development

Do not build features because:

It would be cool if map.ca did this.

Every publicly funded feature should answer:

What resident problem does this solve?

If no answer:

Do not build it with public money.

33.148Public Roadmap

If the system becomes public infrastructure, publish a high-level roadmap.

Possible status:

Proposed

Under Review

Funded

In Development

Pilot

Operational

Stopped

This reduces the tendency to describe every idea as if it already exists.

33.149Prototype Is Not Infrastructure

This distinction should appear throughout the plan.

Prototype

An idea that works under limited conditions.

Pilot

A structured test with real users.

Service

An operating program with support.

Infrastructure

A service with:

Do not skip the ladder.

33.150Do Not Overstate Current Capability

Campaign materials should be precise about what map.ca:

A future roadmap should never be described as operating infrastructure simply because a concept page exists.

Credibility is more valuable than appearing further ahead.

33.151Public Beta

Some early map.ca public-interest services may reasonably launch as:

beta

or

pilot.

Tell users:

Experiment openly.

33.152Owen Sound as Pilot Community

Owen Sound can become the first community to test certain public standards.

That does not mean residents become unpaid technology subjects.

Pilot design should include:

The City is testing a service.

Not experimenting on people without boundaries.

33.153Other Municipalities

If the model works, publish the playbook freely.

The original plan already commits to publishing successful municipal systems so other Canadian communities can adopt them.

That principle should apply strongly here.

33.154Do Not Make Owen Sound a Software Sales Department

The City itself should not become responsible for:

unless a future business case establishes an appropriate municipal structure and lawful public purpose.

More likely:

An independent public-interest organization handles expansion.

Owen Sound shares what it learned.

33.155Municipal Adoption Should Be Voluntary

Another municipality should be able to use:

without being forced into the entire map.ca ecosystem where possible.

Modularity increases adoption.

33.156Local Data Stays Locally Governed Where Appropriate

A national platform can provide common infrastructure.

Each participating municipality should retain appropriate authority over:

National architecture should not erase local accountability.

33.157Common Standard, Local Authority

The ideal may look like:

Common

Local

That allows national scale without nationalizing every municipal decision.

33.158Resident Data Locker

The original plan also proposes a resident data locker that could move from town to town.

That is an ambitious future concept.

It should remain a study during the first term unless privacy, cybersecurity and governance reviews demonstrate a safe design.

A personal data repository creates substantially greater risk than a public map.

33.159Teach Before We Store

Section 31 established the better first step:

Teach residents to organize, back up and control their own information before asking them to store more of it with a public institution.

That remains the priority.

33.160A Data Locker Should Not Become a Dossier

If developed later, a resident-controlled locker should not automatically combine:

The words:

everything in one place

may sound convenient.

They can also describe an enormous breach.

33.161Resident-Controlled Connections

If services can connect to a locker, the resident should understand and control the connection where law permits.

For example:

Allow this document to be shared with this service for this purpose.

Not:

By opening an account you consent forever to everything.

33.162Portability

A true resident-owned data concept should allow the person to move information to another compatible system.

The platform should not say:

Your information is portable

when the export is unreadable anywhere else.

Portability must be practical.

33.163Delete and Disconnect

Users should be able to disconnect optional services.

If a user stops using:

the platform should not keep unnecessary behavioural links simply because the civic account continues.

33.164Data Minimization by Vertical

Each vertical should ask for only what it needs.

YouthMap Browse

Almost nothing.

Event Organizer

Event and organizer information.

RealMap Seller

Property and authorized contact information.

Civic Service Report

Information required to route and follow the service request.

Do not use one universal registration form demanding everything from everyone.

33.165The Public Map Should Work Without a Resident Profile

This should be a technical design objective.

A visitor from:

should be able to use the public map.

Civic information is useful to people who are not registered residents too.

33.166Tourists

Visitors need:

The map can support tourism without building long-term profiles of visitors.

Good information is sufficient.

33.167Businesses

Businesses should be able to maintain accurate public information.

Possible fields:

The platform should not require ongoing content creation simply to remain visible.

A business exists whether or not it posts daily.

33.168No Popularity Contest

Do not rank businesses based on:

A plumber should not need to become a content creator to appear when someone searches:

plumber nearby.

Place and relevance should matter more than attention.

33.169Reviews

A public civic platform does not need to become another:

system.

Private review platforms already exist.

The public map's job is:

Who is here? What do they do? How do I contact them?

That is enough.

33.170Corrections, Not Public Punishment

If a business's:

are wrong:

Correct them.

Do not create an endless public score documenting every mistake a business ever made.

Infrastructure should help discovery.

Not operate a reputation court.

33.171Community Contribution Credits

If future map contributors receive:

for useful public work, the system should ensure rewards do not become civic status.

Contribution recognition can motivate participation.

It should not affect:

33.172Paid Community Mapping

Some mapping work may become legitimate paid work through:

If the City needs recurring verified data collection:

Pay for it appropriately.

Do not build core infrastructure on endless unpaid labour.

33.173Volunteer Mapping

Voluntary contributions can still be valuable.

Examples:

Volunteer status should be clear.

The platform should not promise income simply because someone contributes.

33.174Contributor Safety

Community mapping instructions should never send people into:

The rule is:

Observe from lawful safe locations.

Professional inspection remains professional work.

33.175Photography

Public map photography should avoid unnecessary inclusion of:

A location map does not need to become a surveillance archive.

33.176Location Precision

Some public resources benefit from precise coordinates.

Other information may require less precision.

Do not publish exact locations of sensitive resources where doing so creates:

risk.

Precision is useful only when appropriate.

33.177Historical Information

map.ca could also preserve:

Clearly distinguish:

current

from

historical.

A tourist should not walk to a restaurant that closed in 1974 because the historical layer looked current.

33.178Time as a Map Dimension

A strong civic map should eventually be able to answer:

What is here now?

and separately:

What was here before?

That creates value for:

Do not mix the two by accident.

33.179Public Asset History

For major public assets, residents might eventually see safe history such as:

This connects to the Infrastructure Index.

Maintenance becomes visible.

33.180No Personal Work History of Employees

Asset history should not become:

Employee X made this mistake in 2028.

The public needs:

Employee management remains a separate responsibility.

33.181Procurement Through map.ca

map.ca should not become an alternate backdoor procurement system.

A vendor appearing on the map does not entitle them to:

Municipal procurement continues under Section 11.

33.182Vendor Discovery

The map may help procurement staff discover that local suppliers exist.

Good.

Actual purchasing still follows:

requirements.

Discovery is not award.

33.183Development Information

Public planning and development information may eventually be mapped.

Possible layers:

Use official information.

Do not use community rumours as land-use status.

33.184Zoning

A public map may show zoning information.

It should direct residents to:

where legal interpretation is required.

A convenient map should not be marketed as a guaranteed legal opinion.

33.185Property Boundaries

Likewise, visible map lines should not automatically be represented as:

Label data according to its actual source and precision.

33.186AI Property Interpretation

Do not let an AI assistant say:

You can definitely build this here

based solely on map data.

A better response is:

This information suggests these rules may apply. Confirm with the appropriate City process.

Technology helps navigation.

Government authority remains where law places it.

33.187Public Consultation

map.ca may help residents see:

That can improve participation.

It should not silently infer resident opinion from:

Participation requires intentional input.

33.188Voting and Consultation Data

If VoteMap is ever linked technically to map.ca:

Keep political opinion in a separate protected environment.

A person's public map activity should never reveal how they voted in:

33.189Secret Ballot Remains Secret

Nothing about a unified civic platform should weaken:

The convenience of one account should never override democratic fundamentals.

33.190Public Comment

If map.ca eventually supports public comments:

Design carefully.

A civic map does not necessarily need an endless open comment feed.

Sometimes structured input is better:

Do not recreate social media merely because comments drive engagement.

33.191Engagement Is Not the Goal

Commercial platforms optimize:

Public infrastructure should optimize:

If a resident finds the answer in thirty seconds and leaves:

That is success.

33.192No Addiction Design

Do not use:

simply to increase platform use.

Civic infrastructure should respect attention.

33.193Notification Choice

Residents should choose what they receive.

Examples:

Do not automatically enrol someone in every category.

33.194Emergency Alerts Are Different

True emergency alerts may follow separate legal and operational systems.

map.ca can display official emergency information.

It should not pretend to replace:

33.195Data Sovereignty

Section 32 established the core digital principle:

Keep the ability to leave.

map.ca should be expected to demonstrate that principle more strongly than the average commercial vendor.

If it claims to model digital sovereignty:

It should be portable itself.

33.196map.ca Exit Test

Before City integration, demonstrate:

Data Export

Can City data be exported?

Media Export

Can photographs and files be recovered?

Metadata

Are relationships preserved?

Accounts

Can users transition?

APIs

Are integrations documented?

Domain

What remains if the platform changes?

Replacement

Can another provider reconstruct the public service?

Test it.

Do not merely promise it.

33.197Public Fork

For suitable open components, consider whether another municipality could independently operate the software if the central organization failed.

That may not be feasible for every component.

Where it is:

It provides a powerful continuity safeguard.

33.198A Platform Cannot Hold the Public Hostage

If a future board says:

Pay whatever we demand or your civic map disappears,

the governance model failed.

Public partners need contractual and technical exit rights.

33.199Service-Level Agreements

For municipal integrations, define reasonable:

A public-interest nonprofit still needs professional operating agreements.

Good intentions are not service levels.

33.200Accessibility-Level Agreements

Likewise, accessibility should be maintained through:

A public site can become inaccessible over time as features are added.

Accessibility is maintenance.

33.201Privacy by Design

Every new feature should pass:

Can we provide this with less personal information?

That should become part of development review.

Privacy added after launch usually costs more and works less well.

33.202Security by Design

Similarly:

belong in the design.

Do not build quickly and promise:

We'll secure it later.

Public infrastructure deserves better.

33.203Accessibility by Design

The same is true for accessibility.

Do not launch:

version one for everyone else

and promise disabled residents version two.

Design the core access correctly from the beginning.

33.204Human Support

A public digital system needs a way for people to say:

This is wrong.

or:

I cannot use this.

Provide human support appropriate to the scale of the service.

Automation should reduce repetitive support.

Not eliminate accountability.

33.205Support Cost

Human support costs money.

Include:

Software development is only part of platform cost.

33.206Fraud Team

As use grows, some form of fraud and abuse handling may become necessary.

Possible problems include:

Start proportionately.

Do not build a national enforcement department for a local pilot.

Scale controls with actual risk.

33.207Law Enforcement Requests

A public platform should establish a lawful process for responding to requests from police or other authorities.

Do not casually hand over resident information because someone says:

This is for safety.

Follow:

33.208Transparency Reporting

As the system grows, an independent public-interest operator could publish aggregate information concerning appropriate categories of government or legal requests where law permits.

The purpose is accountability.

Not obstruction of lawful investigations.

33.209Private Messages

If map.ca ever introduces private messaging:

That creates another category of sensitive information.

Do not add it casually.

Ask:

Does the public purpose actually require us to operate a communications service?

A link to:

may be enough.

33.210Feature Restraint

The best map.ca may be smaller than the biggest map.ca imaginable.

A platform becomes fragile when every good idea is added to the same system.

The core could remain:

Other services can integrate without being swallowed.

33.211Modular Architecture

RealMap.

YouthMap.

Community Calendar.

First to Action.

Shop Local.

These can share standards while remaining modular.

If one module:

the entire civic information system should not collapse.

33.212Separation Protects Innovation

A modular structure also allows one team to improve:

without risking:

Good boundaries help innovation move faster.

33.213Separation Protects Privacy

The same architecture reduces pressure to create one enormous dataset.

Each module can operate with the minimum information it needs.

That is better civic design.

33.214The Map Council Sees Is Not the Database

Residents may see one visually unified interface.

Internally, information can remain separated by:

One map does not require one database.

33.215Public Search Does Not Require User History

A high-quality local search system can work using:

It does not need years of behavioural history.

That should be the default.

33.216Community Ownership Does Not Mean Everyone Can Edit Everything

Public ownership should not be confused with:

any user can alter official information.

Permissions remain.

Examples:

City Staff

Maintain official municipal data.

Business

Maintains its own business information.

Event Organizer

Maintains their event.

Resident

Can suggest corrections.

Public ownership means accountable governance.

Not an editable free-for-all.

33.217Provenance

Important information should preserve where it came from.

For example:

Source: City of Owen Sound

Source: Business owner

Source: Community submission

This helps residents judge reliability.

33.218Uncertainty

Sometimes information is incomplete.

Say:

Unverified.

or:

Last confirmed June 2027.

Do not fill the blank with AI-generated certainty.

33.219No Fake Completeness

A map may show ten businesses in a category.

That does not necessarily mean:

These are every business in Owen Sound.

If participation is incomplete:

Say so.

Public users should understand coverage.

33.220Open Participation

Eligible organizations and businesses should have a reasonable way to:

their presence.

The system should not require insider access.

33.221No Pay-To-Be-Found

Basic local discovery should remain independent of advertising spend.

That is one of the strongest public-interest differences map.ca could offer.

If visibility becomes purchasable:

The public-purpose case becomes weaker.

33.222No SEO Arms Race Inside the Public Map

Businesses should not need to publish:

just to appear.

Use structured factual categories.

The local mechanic should appear because they are:

a local mechanic.

Not because they hired the best optimization company.

33.223Simple Business Tags

Possible tags:

Tag standards should be understandable.

Do not create 15,000 obscure classifications that only platform staff understand.

33.224Disputed Categories

A business may disagree with its classification.

Provide correction.

Do not allow competitors to sabotage each other's categories.

The listing owner and platform rules determine the public description.

33.225Canadian Product Discovery

Future Shop Local features may help residents discover:

Any origin claim should be based on information supplied by an appropriate:

Do not infer national origin from branding.

33.226Public Procurement Remains Separate

Even if map.ca shows Canadian suppliers:

The City continues to purchase under:

Map visibility is not procurement preference.

33.227Environmental Information

Public environmental information may be useful.

Examples:

Do not allow unqualified platform users to publish:

as official facts.

Use the appropriate authority.

33.228Health Information

Likewise, HealthMap-style services may eventually exist.

A public map can show:

It should not diagnose:

Medical information deserves a higher governance threshold.

Do not expand there casually.

33.229Safety Information

Avoid broad labels such as:

Safe Place

unless the term has a precise program definition.

Conditions change.

A map can describe:

Let users make informed choices.

33.230"Safe" Is Not a Guarantee

This principle applies throughout map.ca.

A database can help someone make decisions.

It cannot promise:

Use objective description over sweeping reassurance.

33.231Public Information Liability

The operator should maintain clear disclaimers appropriate to information that may:

A disclaimer should not become an excuse for careless data.

Accuracy remains the objective.

33.232Insurance

An independent operator may require appropriate insurance relating to:

The exact coverage belongs to professional advice and the final structure.

Include insurance in complete cost.

The existing working paper correctly states that final:

requires qualified Ontario municipal, privacy, procurement and related legal advice based on the law and facts when a decision is actually made.

That disclaimer belongs permanently in this initiative.

This plan is a governance framework.

Not a substitute for transactional legal work.

33.234Independent Technical Review

Legal approval is not enough.

A platform may be lawful and technically poor.

Before municipal adoption:

Review:

The reviewer should not be chosen by the founder alone.

33.235Independent Privacy Review

The same applies to privacy.

Ask:

Publish an understandable public summary.

33.236Independent Accessibility Review

Test both:

Bring people with disabilities into the evaluation before final procurement.

33.237Independent Financial Review

Before public transfer:

Publish:

No:

It's basically free because the code already exists.

Existing code is only the beginning of operating cost.

33.238Independent Competition Review

Ask:

Would municipal adoption unfairly distort a market or grant inappropriate advantage to one private enterprise?

The RealMap work already identifies this as part of the legal and governance firewall.

If the answer reveals a problem:

Redesign.

33.239Decision Gate 1: Public Purpose

Before adoption, Council must answer:

What specific municipal public purpose is served?

Not:

The technology is impressive.

33.240Decision Gate 2: Ownership

Identify exactly:

No ambiguity.

33.241Decision Gate 3: Founder Interest

Publish relevant:

Do this before the vote.

33.242Decision Gate 4: Independent Valuation

No transfer without an appropriate arm's-length understanding of value.

Confirm the City has authority for:

Do not infer authority from enthusiasm.

33.244Decision Gate 6: Conflict Compliance

Confirm:

The person with the interest does not lead the decision.

33.245Decision Gate 7: Procurement

Determine whether:

applies.

Publish the rationale.

33.246Decision Gate 8: Privacy

Complete privacy review.

No unresolved:

before launch.

33.247Decision Gate 9: Cybersecurity

Complete technical security review and identify:

The public summary can protect sensitive detail.

33.248Decision Gate 10: Accessibility

Prove the service works for people with disabilities.

Not merely that the vendor says it does.

33.249Decision Gate 11: Portability

Export the information.

Demonstrate that it can be used elsewhere.

33.250Decision Gate 12: Financial Sustainability

Show:

No hidden future bill.

33.251Decision Gate 13: Non-Digital Alternative

Ask:

Can a resident still receive essential municipal service without map.ca?

If no:

The system has become mandatory infrastructure and needs a substantially higher continuity standard.

33.252Decision Gate 14: No Private Windfall

Council should receive an explicit report answering:

Does this transaction create a direct or indirect private advantage connected to an elected office-holder beyond what has been independently reviewed and justified?

Do not leave the most important question unstated.

33.253Decision Gate 15: Public Exit

Before entry:

Show how the City exits.

A relationship without an exit plan is dependency.

33.254First 30 Days

The first month should not involve City adoption.

It should involve disclosure and independence.

The existing working paper already proposes early ownership and conflict disclosures, independent legal and professional advice and a neutral evaluation process.

Actions

  1. Publish current map.ca and RealMap ownership relationships relevant to public evaluation.
  2. Declare relevant personal or corporate interests.
  3. Request independent municipal legal and integrity advice.
  4. Direct staff to define the public-information problem without assuming map.ca is the answer.
  5. Establish the public Digital Infrastructure Standard.
  6. Prevent the Mayor from directing the platform evaluation where conflict rules require or public trust warrants separation.

33.255Days 31 to 60

During the second month:

  1. complete asset inventory;
  2. complete preliminary valuation;
  3. complete technical architecture review;
  4. begin privacy review;
  5. begin accessibility testing;
  6. assess municipal-assistance and competition issues;
  7. document five-year cost;
  8. test data export;
  9. compare governance options;
  10. identify at least one credible non-map.ca implementation alternative.

A real evaluation requires alternatives.

33.256Days 61 to 100

The existing RealMap framework already calls for publication of legal conclusions, costs, consultation findings and a Council decision on whether a governance path should proceed.

For map.ca specifically:

Publish:

What map.ca currently does

What remains prototype

Assets

Ownership

Valuation

Conflict findings

Privacy findings

Cyber findings

Accessibility findings

Governance options

Five-year financial model

Portability findings

Recommendation

Then Council decides whether further evaluation deserves public resources.

Not whether the Mayor wins.

33.257Year One

During Year One:

No essential municipal function should depend exclusively on map.ca in Year One.

33.258Year Two

If Year One succeeds:

Scale one step at a time.

33.259Year Three

If governance remains strong:

Do not introduce high-risk features merely because adoption increased.

33.260Year Four

By Year Four, publish a full map.ca Public Infrastructure Report.

Ask:

Is the public purpose clear?

Is basic civic access free?

Is browsing possible without an account?

Is the calendar free of paid ranking?

Is basic civic search free of advertising influence?

Are residents tracked unnecessarily?

Can businesses and organizations correct their information?

Can people with disabilities use the service?

Is there a meaningful non-digital route?

Does RealMap remain optional?

Does YouthMap map opportunities rather than children?

Are political and civic-service data separated?

Does the Mayor retain any financial benefit or control?

Is the organization independent of its founder?

Can the City export its data?

Has that export been tested?

Can another platform use the public standard?

Can Owen Sound leave map.ca without losing the public service?

Does the operating model survive without a temporary grant?

Has another Canadian municipality been able to reuse the model without surrendering its own authority?

If those questions cannot be answered well:

Do not call it public infrastructure.

33.261The Founder Test

At the end of the term, apply one unusual but important test:

What happens if Mike Seiler disappears tomorrow?

Does the platform:

If the answer is:

We need Mike,

then I have not successfully made it public infrastructure.

33.262The Election Test

Then ask:

What happens if the next Mayor dislikes map.ca?

If the public institution can:

through lawful governance:

Good.

If I retain the power to stop that:

It was never truly public.

33.263The Vendor Test

Ask:

What happens if the hosting provider doubles its price?

Can we move?

33.264The Cyber Test

Ask:

What happens if the main system is compromised?

Can we:

33.265The Privacy Test

Ask:

Could someone use this system to reconstruct a resident's life?

If yes:

We collected or connected too much.

33.266The Accessibility Test

Ask someone who does not use the map visually:

Can you still find what you need?

If not:

The map is not public enough.

33.267The Poor Resident Test

Ask:

Can someone participate with no credit card and an older device?

If not:

Review the public-access claim.

33.268The No-Smartphone Test

Ask:

Can someone access essential municipal information without owning a smartphone?

The answer must remain:

Yes.

33.269The Business Test

Ask a small local business:

Can a customer find you without paying the platform for visibility?

The answer should be:

Yes.

33.270The Political Opponent Test

Ask:

Can someone who strongly opposes the Mayor receive the exact same platform access?

The answer must be:

Yes.

33.271The Faith Test

Ask:

Can a church, mosque, secular group and political association all use eligible public calendar functions under the same rules?

The answer should be:

Yes.

33.272The Child Test

Ask:

Can a teenager find an opportunity without the platform building a permanent behavioural profile of them?

The answer should be:

Yes.

33.273The Other-Municipality Test

Ask:

Could another Canadian municipality use our standard without becoming dependent upon Owen Sound?

If yes:

We built infrastructure.

If no:

We may simply have built another vendor.

33.274The Public Ownership Test

The deepest test is:

Does the public actually control the public purpose?

Not:

Does government own every line of code?

Public control means:

Ownership is one possible tool.

Not the only one.

33.275What map.ca Should Never Become

map.ca should never become:

If it becomes any of those things:

The public infrastructure experiment has failed.

33.276What map.ca Could Become

If built properly, map.ca could become something much simpler and more useful:

A public-interest layer that helps people understand what exists around them.

Where is:

Who maintains the information?

When was it verified?

How do I learn more?

That alone can create substantial civic value.

33.277Public Infrastructure Should Reduce Friction

The test is not:

How many features does map.ca have?

The test is:

How many ordinary questions can a resident answer more easily?

If it becomes complicated enough that residents need training merely to find a park:

We have failed.

33.278Public Infrastructure Should Increase Choice

A healthy map should lead outward.

It should help residents reach:

It should not trap every interaction inside itself.

33.279Public Infrastructure Should Be Boring Sometimes

Successful infrastructure often becomes invisible.

You do not celebrate the water main every morning.

It simply works.

map.ca should eventually be judged the same way.

Not by:

By whether residents can depend upon the information.

33.280Public Infrastructure Outlives Personalities

This is the final institutional test.

The strongest outcome for something I helped create would not be having my name permanently attached to it.

It would be reaching the point where my name no longer matters.

Another Mayor.

Another Council.

Another developer.

Another technology provider.

The public purpose continues.

That is what it means to build something for the community rather than for the founder.

The map.ca Public Infrastructure Commitment

The original vision is bold:

protected public ownership, a lasting civic address, RealMap, YouthMap, one community calendar and resident-controlled data tools.

The governance protecting that vision needs to be even stronger.

The commitment is:

Define the public problem before selecting the technology.

Build the open public standard before adopting map.ca.

Allow Council to reject map.ca while keeping the public standard.

Disclose every relevant ownership and financial relationship.

Obtain independent valuation.

Obtain independent municipal, procurement, privacy, conflict, competition, accessibility and cybersecurity review.

Keep the Mayor out of decisions where a conflict exists or public trust requires independence.

Never use strong-mayor authority to force adoption of a Mayor-related platform.

No founder procurement design.

No founder valuation.

No founder veto.

No automatic perpetual royalty.

No hidden related-company dependency.

Use an open municipal standard first.

Consider an independent public-interest ownership structure only after it passes review.

Do not make direct municipal ownership the first assumption.

Transfer only the assets the public purpose actually requires.

Secure institutional control of public domains and administrative systems.

Make the platform function without its founder.

Make basic civic information free to browse.

Do not require an account for ordinary public information.

Do not confuse a civic email address with legal identity.

Turn "email for life" into a real portable-governance model before making a literal lifetime guarantee.

Map opportunities, services and places, not vulnerable residents.

Keep YouthMap focused on youth opportunities rather than youth profiles.

Keep RealMap optional.

Keep the community calendar free to list and free to browse under neutral rules.

No paid ranking in the public layer.

No behavioural advertising.

No selling resident search histories.

No political use of civic-service data.

One doorway does not mean one giant resident profile.

Separate data by purpose.

Collect only what the public service actually needs.

Make source and verification clear.

Allow corrections and appeals.

Keep official information distinct from community-submitted information.

Use AI to help people understand information, not to become an invisible civic authority.

Do not use private resident information for unrelated AI training.

Build accessibility into the platform before municipal adoption.

Preserve telephone, paper and human service.

Publish safe open data where appropriate.

Use open interfaces and portable standards where practical.

Keep the ability to change technology providers.

Test the export.

Test the backup.

Test the restore.

Test the exit.

Know who pays after grants end.

Show the complete five-year public cost.

Do not allow public infrastructure to become a private windfall later.

If other Canadian municipalities adopt the model, let them retain their own local authority.

Publish the playbook freely.

Make map.ca unnecessary to the policy, and make the founder unnecessary to map.ca.

The strongest possible proof that map.ca became public infrastructure would not be that Owen Sound could never live without map.ca.

It would be the opposite.

Owen Sound could replace the software tomorrow and still retain the public information, the public standards, the public identity, the public governance and the public service.

That is the difference between a platform and infrastructure.

A platform asks:

How do we keep the user?

Public infrastructure asks:

How do we keep the service working for the public?

Build the standard first. Protect the public purpose. Separate private advantage from public power. Keep the information portable. Keep the resident free. Then let the technology earn the right to become infrastructure.

← Chapter 32: Canadian Digital SovereigntyChapter 34: A Formal Relationship With Saugeen Ojibway Nation →