Submission — Public consultation on advancing AI transparency in Canada

1. Who is submitting this

I am an audio engineer and software engineer in Saskatchewan. I have used generative music tools at high volume — thousands of tracks generated and released through commercial distribution — and I spent the past year attempting to verify, attribute, decompose, and transcribe the results, which is what produced this submission. Until early 2026 I moderated a Suno practitioner community of approximately 50,000 members; I no longer hold that role, and the observations I draw on that experience are labelled where they appear. Software I built in the attempt is public and inspectable, and the method and its limits are documented in the accompanying field report.

I can describe what that population does with these tools, and I can serve as a research subject. I cannot convene it on the government's behalf, because I am no longer part of it.

2. The finding

Present audio detection should not be the enforcement basis for a per-work labelling mandate. It performs well on clean, fully-generated tracks and degrades sharply on hybrid and post-processed material — which is precisely the case ISED's own discussion paper puts at the centre of this question: “A musician may generate an instrumental backing track with AI and layer original vocals over it. In each case, reasonable people may disagree about whether the result should be characterized as AI-generated.”

Detectors reach over 99% accuracy on clean, fully-generated tracks — unprocessed, full-length, containing no human contribution. In broadcast-style conditions, with masking and short excerpts, F1 falls below 60%. On hybrid human-AI material, a study that synthesizes hybrids by codec-reconstructing real stems and then runs detection after source separation reports false-positive rates of 94.7% for the naive separation-then-detect approach and 26.2% for the authors' improved method, which the authors still describe as carrying “a significant amount of false positives.” Those are experimental rates under that study's specific design, not field rates on released hybrids; the direction, however, is not in dispute, and separation does not isolate the generated component — artifacts from it spread across every separated stem.

Watermarking is not the fallback it is often assumed to be. The most comprehensive available multi-domain assessment of audio watermarking, which covers music as well as speech, finds neural compression the hardest case for every system tested, including systems trained against compression. Post-hoc watermarks are weaker still: a speech-domain study (Northwestern University; Adobe Research) removed state-of-the-art post-hoc watermarks with no knowledge of the watermarking scheme and minimal degradation in audio quality, driving true-positive detection to 0.00% at a 1% false-positive rate. That study is speech-scoped and should not be read as a music result on its own; its significance here is that the mechanism is ordinary post-processing, and post-processing is routine in music production. The discussion paper describes audio marking as “comparatively well developed” relative to text. For music specifically, that relative optimism is not what the published evaluations show.

The second finding is about a class of systems, and the scope matters because the recommendation depends on it. Full-mix generators — the Suno-class systems that take a prompt and return a finished stereo mix, without exposing per-stem generation — do not produce a mix of instruments. They produce one sample from a joint probability distribution over a summed signal. At no point in generation does a per-instrument representation exist. For these systems, per-component attribution is not a hard problem but a category error: there is no component structure in the generation process for an attribution method to recover. The published literature has arrived at this independently from two directions — detectors trained only on fully-generated or fully-human tracks become “noisy and miscalibrated” when the two are mixed in one signal, and detection applied after source separation fails because there is nothing component-shaped to recover.

This is not a claim that no generative audio system can support attribution. Stem generators and DAW-style interfaces do emit per-stem audio, and hybrid workflows use stems as mixing units. The claim is narrower and, for policy purposes, harder: the systems that produce the released corpus cannot support it, and a regime built on decomposing their output would be built on something that does not exist. This is why the disclosure recommended in §4 is a disclosure about the output of full-mix generators specifically.

I reached the practical version of this before the literature. Masters produced from generated tracks using an ML-based mastering processor passed platform-side AI detection at the time I was doing the work. Passing was not a trick. It was ordinary post-production.

3. Consultation question 3.1 — Detecting and identifying AI-generated content

Asked whether existing tools and frameworks make it easy enough to know when content is AI-generated, and what action should follow: no, and the gap can be named precisely, because Canada already has the instrument.

ISED's Voluntary Code of Conduct on the Responsible Development and Management of Advanced Generative AI Systems (the Code) commits developers of publicly available advanced generative systems to “develop and implement a reliable and freely available method to detect content generated by the system, with a near-term focus on audio-visual content (e.g., watermarking).” For audio, the evidence in §2 indicates that commitment cannot be met as written — not because signatories have failed, but because the capability does not exist at the reliability the commitment implies. A voluntary commitment that cannot be satisfied as drafted does not produce transparency; it produces an unverifiable claim of compliance.

Recommendations

1. Make the detection commitment condition-specific. Where a developer reports detection performance, require it by condition: fully generated, hybrid, short excerpt, broadcast-masked, post-processed. A headline accuracy figure describes material almost nobody ships. Instrument: guidance; a candidate standard through the Standards Council of Canada's AI program. Actor: developers.
2. Do not make per-work labelling contingent on per-component attribution. Where accuracy in a declared condition falls below a stated floor, that should be published as a limitation rather than used to label a work. Instrument: guidance, or legislation if the obligation is to be binding. Actor: developers and platform deployers.
3. Design for hybrid as the primary case. It is the case the discussion paper names, the case practitioners produce, and the case that evades detection. A binary label that misclassifies human-authored work is worse than no label for the person carrying it, so false-positive risk belongs in the design requirements rather than in the caveats. Instrument: guidance. Actor: developers and deployers.
4. Prefer process disclosure to decomposition. What a system is, what it was trained on, what it cannot do, and whether a human made the consequential creative decisions. Process is documented and checkable; component-level attribution of a full-mix output is neither. Instrument: guidance; the Code's transparency section already points this way. Actor: developers.
5. Treat practitioners as an evidence source in their own right. The current record is built from platform self-reports, vendor claims, and rightsholder positions. The people generating at volume appear in none of them, and their practice is where the failure modes actually surface. My own vantage point is stated in §1. Instrument: consultation design, and R&D through CAISI, which funds research via CIFAR and through government-directed projects. Actor: ISED and CAISI.

Context from industry practice, offered as analogy rather than recommendation. SOCAN's registration guidelines, published 28 October 2025 alongside ASCAP and BMI, state that AI-assisted works are registrable and that “you don't need to disclose how AI was used when registering your AI-Assisted Work with SOCAN.” SOCAN's own FAQ states that identifying AI outputs that use a member's songs is “not reliably today” possible, and the reported partnership with Musical AI is at proof-of-concept stage. A rights organisation whose revenue depends on accurate attribution has therefore adopted a trust-based regime for AI-assisted works rather than a disclosure-based one. The relevance is not a request that ISED comment on that program; it is that the largest Canadian rights organisation operating in this space has already concluded per-work AI disclosure is not currently verifiable, and designed accordingly.

4. Consultation question 3.3 — Information about AI systems and their limitations

Asked what information would let users make informed choices: the specific and consequential gap is a limitation no major generative audio vendor discloses. Exported stems from a full-mix generator are post-hoc estimates produced by a separation tool's decisions, not components recovered from the model. Nothing in the interface or the documentation says so.

Practitioner observation, from the position stated in §1: the community I moderated pursued stem separation obsessively — an entire ecosystem of third-party tools exists to attempt it — because practitioners read the failure as immature tooling. It is not immaturity. It is mis-specification. They are diagnosing a property of the generator as a defect in the product, and spending money and months on it.

Recommendation: a disclosure sentence, and it requires no new instrument. The Code already commits developers of publicly available systems to “publish information on capabilities and limitations of the system.” A statement that stem exports from full-mix generators are estimates, not components, is an instance of that existing commitment rather than an extension of it, and the developer is the only party in the value chain positioned to make it — only the developer knows the architecture. Instrument: guidance under the existing Code; optionally a definitional standard via the Standards Council of Canada. Actor: developers of full-mix generative audio systems. This is the cheapest transparency intervention available in this category: one sentence, correcting a widespread and expensive misunderstanding.

5. Consultation question 3.3 — Disclosure of training data, including copyright-protected material

Section 3.3 raises training data directly and asks how input transparency should be balanced against the protection of confidential business information. On the first part:

Training-data disclosure will not, by itself, produce attributability, and it should not be promoted as if it will. If a full-mix model learns a joint distribution over mixtures (§2), then a complete and honest manifest still does not tell a rightsholder which component of a given output came from their work. Publishing training records is valuable — for research, for consent enforcement, for licensing negotiation — but for these systems it is not a step toward per-output attribution, because there is no per-output component structure to attribute. Expectations should be set accordingly on all sides, before compliance infrastructure is built on the assumption that a manifest implies an answer.

On the balance question, the two interests are separable. Dataset composition and provenance at the input stage is a different object from model internals: a description of what categories of protected material were used, from what sources, and on what licensing basis discloses nothing about architecture or weights. The Code already commits developers to publish “a description of the types of training data used to develop the system.” That commitment is currently too general to be checkable; making it specific enough — categories, sources, licensing basis — advances transparency without reaching the confidential business information the discussion paper is concerned with.

6. Consultation question 3.4 — Enabling the tracking of serious incidents related to AI systems

Asked how a serious AI incident should be defined, how reporting should be structured to encourage disclosure while protecting confidentiality, and who should report: the gap can be stated in three clauses, and this section's finding is that all three are empty.

Canadian frameworks address privacy breaches, cybersecurity incidents, and sectoral safety events. None reaches an event in which an AI system's own operation destroys the ability to attribute authored work. There is no operator-facing duty to notify affected users when a system crosses between their data stores, no requirement to produce a transfer manifest recording what moved, and no incident category for provenance loss. That is the gap.

The incident, at the level of mechanism. In 2026, an AI system operating across a shared document workspace merged two users' document stores, making each store's contents accessible to the other user. Neither party was notified by the operator; each discovered the exposure independently. No remediation was offered or available. The merge damaged no file — what it destroyed was the record of authorship. Because the two stores were combined, neither party can now establish which authored work products originated with whom. A body of authored work still exists and can no longer be reliably attributed, which is the failure mode this consultation examines elsewhere arriving here through an AI system's own operation.

That is the whole of the incident, and it is stated at this level deliberately. Reporting an event of this kind should not require the reporter to disclose the material that crossed, and the participation terms for this consultation direct participants not to include confidential information about any person. De-identification here is not caution; it is a demonstration of the design problem. A reporting requirement satisfiable only by describing another party's files will not be satisfied.

On the definition and threshold. A serious AI incident should be defined to include events in which a system's operation makes previously attributable authored work unattributable — including where no personal information is involved and no file is lost. The threshold that avoids over-reporting is scope, not severity: attach the duty to systems that operate across user data boundaries (multi-tenant systems with sync, merge, or cross-store functions) rather than to AI deployments generally. The confidentiality and liability concerns the discussion paper raises are manageable at that scope, because what is reportable is the event category and the data categories affected, not the content.

On who reports and who collects. The operator or deployer of the system that performed the merge is best placed to report: the developer may not see individual tenant events, and the affected user cannot know the event occurred. Notification and reporting are therefore separate obligations on the same party — notification to affected users with an accounting of what moved, reporting to the collector at the level of category.

Recommendations

1. Define provenance loss as a reportable incident category, distinct from privacy breach. Nothing technically goes wrong with the files, which is exactly why no existing framework reaches it. Instrument: legislation, or in the first instance guidance defining the category under the Code's incident-database commitment. Actor: operators and deployers.
2. Create a channel that accepts de-identified reports, and name the collector. Instrument: guidance plus a government-directed project at CAISI, which is mandated to work on synthetic-content risk and to provide guidance to developers and users. Collector: a single designated authority — not a public-reporting tracker, since trackers that rely on voluntary public disclosure inherit precisely the visibility gap described here. Actor: operators report; researchers and policymakers receive.
3. Require a transfer manifest when a system merges, syncs, or crosses data stores. Instrument: a standard, via the Standards Council of Canada, defining an interoperable manifest format; or a procurement requirement for systems sold into the federal government, which would establish it without legislation. Actor: developers build the capability; operators produce the record and provide it to affected users.
4. Treat provenance destruction as a harm in its own right. No remedy exists under current frameworks, because nothing went wrong with the files themselves. Instrument: the definition in recommendation 1; guidance first, legislation if it is to be enforceable. Actor: operators and deployers.

7. What I am asking ISED to take from this

1. Make the Code's detection commitment condition-specific, and publish accuracy by condition.
2. Do not condition per-work labelling on per-component attribution of a full mix.
3. Prefer process disclosure to decomposition.
4. Require the stem-export disclosure from full-mix generators — one sentence, no new instrument.
5. Keep training-data manifests in scope, and do not present them as per-output attribution.
6. Add provenance loss to the incident categories, with a channel that accepts de-identified reports.
7. Treat practitioners as an evidence source, not only as an audience (as noted in §1).

I am available to appear, to provide data, to serve as a research subject, or to be contacted for follow-up. The accompanying field report documents the method, the instruments, and the limits of these findings in full. Two of the tools described in it are public and inspectable: github.com/sgm-audio/tab-agent-pro and github.com/sgm-audio/stem-midi-pro.