A demonstration is filmed; what the territory keeps afterwards is rarely asked. Funding a durable capability, baseline, operating costs, continuation criteria, rather than a demo.
Most publicly funded digital projects are judged on what they demonstrated. The demo is filmed, the room applauds, and the evaluation closes on a delivery date. What is rarely asked is what the territory keeps afterwards: the ability to keep the information correct, the human effort to do it, and the freedom to move it elsewhere without renegotiating from zero.
This article argues that those questions belong in project design rather than in the post-mortem, and describes what funding a durable capability would look like alongside, not instead of, a demonstration.
In Québec's tourism sector, the information infrastructure is already public. SIT Québec, run by the Government of Québec, manages and distributes the tourism data that tourism organizations supply, feeding Bonjour Québec and the visitor-information network. Datasets are published through Données Québec.
Any project proposing to work with tourism member data should therefore state plainly where it intervenes. There is a five-step chain that most contributions follow: a member business describes an update; the update is clarified where something is missing or ambiguous; the information is structured into fields; the responsible team validates it; and the validated information reaches the systems and channels it feeds.
A project that helps at the clarification or structuring step is not competing with SIT Québec. A project claiming to replace it would need to say what it does with validation and distribution, and would face a verification burden with the custodians of those systems rather than a comparison.
France offers a useful contrast in governance. DATAtourisme operates as a national channel fed by more than forty territorial databases, with collective funding behind the platform and a semantic model that gives regional data a shared shape. Its value to a funder is not the platform itself but the pattern: shared meaning, distributed production, explicit rules about who owns what after the pilot ends.
France is a reference point here, not a template. A provincial system and a national platform differ in scale and governance, and nothing in this article measures either against the other.
The work of keeping information correct is ordinary work, and ordinary work rarely appears in a project's budget narrative. It belongs there.
Five cost lines deserve explicit attention when a project is designed. Member participation: the time businesses spend describing and confirming their own information, time that comes out of their operations. Accompaniment: the follow-up a team does when updates arrive as scattered messages or ambiguous descriptions. Exceptions: the cases no structured field anticipates, which fall to someone to resolve by hand. Validation: the review that keeps incorrect information out, which is the responsibility of the organization, not of the tool. Upkeep: the recurring effort of keeping definitions, interfaces and documentation current after the project closes.
Each of these can be scheduled and measured. None of them belongs in a category called "operational" to be absorbed silently at the end of a funded mandate. A project that names them is not more expensive; it is more honest about what it is buying.
One caution on funding language: none of these costs can be declared eligible under a specific program's rules without checking those rules with the program itself. This article describes no particular program, no subsidy rate, and no eligibility determination, and none should be inferred from it.
A pilot that begins without a baseline cannot be honestly evaluated, and a demonstration is not a baseline. Before anything changes, the current state should be recorded: how complete member records are, how current they are, how much human effort their upkeep consumes, and where errors are corrected with what delay.
During the pilot, three things are worth measuring together, because they trade against each other. Quality: are records more complete and more current? Human effort: is clarification and validation time per update falling, holding, or rising? Continuity: does the information still flow to the systems and channels that consume it once the pilot's extra attention is withdrawn?
The third one is the one that distinguishes a capability from a temporary improvement. Continuity is what shows whether the arrangement survives its own funding period.
A project should also name, in advance, the criteria that would mean continuing, modifying, or stopping. Those criteria are most useful when they are written before the results are known, because a pilot that cannot fail is a demonstration with a budget.
Portability is usually asserted and rarely tested. A cheaper and more honest approach is to propose a reuse test before the pilot ends.
The test is concrete. After the pilot, ask whether a defined extract can be produced, say, the member records with their validation history, and whether the receiving party, including a third system, can use it as intended. Then ask what that exchange required: which rights had to be clarified, whose definitions governed each field, which dependencies on pilot-only tooling were carried along, and what it cost in effort.
These questions produce narrower statements than "the solution is portable", and narrower statements are the ones that hold up later. They also often reveal that the real portability risk is not the data format but the definitions: two systems can agree on a field name and still disagree on what it means.
A durable capability is not a tool left installed. It is a practice a region can continue: knowing which information matters, who validates it, how effort is budgeted, and how the result reaches the channels that depend on it.
Financing that outcome means funding the operating discipline, not only the build. It means the follow-up work appears in the project's own plan with its own owners. It means validation responsibility stays where the organization's members and its public infrastructure expect it. It means the evaluation asks, before closing, what the territory is able to do without the project's particular support, and whether that answer is good enough to keep going.
That last question is the one this series has been building toward. The first article asked what a tourism database is for. The second asked why member information belongs on a board's agenda. This one asks what it takes to keep the answer true after the funding cycle ends.
ISOD Enrichissement, co-developed by UPentreprise and Storyline Communication, is a conversational approach to member-data contribution: a member business describes an update in its own words, the interaction identifies what is missing or ambiguous, the information is prepared as structured fields for the organization's team to validate, and agreed arrangements determine how validated information reaches existing systems. Integration with systems such as SIT Québec and Tourinsoft would be defined per interface and permission.
It is published here in that capacity, an approach to evaluate, not a result to assume. No results, integrations, or funding outcomes are presumed here, and any evaluation would begin with the baseline and criteria described above.
Does this add infrastructure where none exists? No. The article's premise is the opposite: Québec already runs SIT Québec, and the questions are how member contributions reach it, how they are validated, and who maintains that. Any project should say where in that chain it works.
How do we know the capability will outlast the funding? The proposal should name the baseline it will be judged against, the criteria for continuing, modifying or stopping, and a reuse test proposed before the pilot closes, what can be exported, under whose definitions, with what rights and at what cost. A capability that cannot be described in those terms is not yet one.
What does the operating discipline cost? The five cost lines named here, member participation, accompaniment, exceptions, validation and upkeep, are the ones most often left implicit. Naming and scheduling them is what turns a demonstration into something a region can keep. None of this article constitutes a funding determination, a rate, or an eligibility ruling under any program.
Naming those costs before a project starts is also what lets a funder compare a proposal on its own terms. ISOD Enrichissement sets out where such a proposal would sit on the contribution chain described above, and what its integration would depend on.
No. The article's premise is the opposite: Québec already runs SIT Québec, and the questions are how member contributions reach it, how they are validated, and who maintains that. Any project should say where in that chain it works.
The proposal should name the baseline it will be judged against, the criteria for continuing, modifying or stopping, and a reuse test proposed before the pilot closes, what can be exported, under whose definitions, with what rights and at what cost. A capability that cannot be described in those terms is not yet one.
The five cost lines named here, member participation, accompaniment, exceptions, validation and upkeep, are the ones most often left implicit. Naming and scheduling them is what turns a demonstration into something a region can keep. Nothing in this article constitutes a funding determination, a rate, or an eligibility ruling under any program.
