I. The IP Problem on Crown Contracts
Standard Ontario government contract language — including IO's AFP project agreements — contains a clause that assigns ownership of all "deliverables" and "work product" developed under the contract to the Crown or the prime contractor. This is the default. If EOSE deploys fleet technology (PEMOS engines, γ₁ routing, PEMCLAU vectors) on the SSE project without a carve-out, there is a legal argument that IP developed during the engagement belongs to STC, Metrolinx, or the Province.
Alan's role: map the IP landscape precisely and build the contractual defences that protect EOSE's position.
The Two IP Categories
Background IP (ours) vs. Foreground IP (project-specific, negotiated)
Background IP: Everything EOSE created before the engagement begins. γ₁ = 14.134725141734693, the PTTE framework, PEMCLAU architecture, all registered Novel Patterns, all existing ARBs. This is ours. It cannot be claimed by the contract. It must be explicitly listed in an IP schedule attached to any subcontract.
Foreground IP: IP developed specifically for the SSE project — custom station monitoring modules, Metrolinx-specific integrations, project-specific data pipelines. This is negotiated. Default position: joint ownership with a license grant to EOSE for non-competing use.
II. The γ₁-Anchored Novel Pattern Defence
EOSE Novel Patterns are timestamped in the fleet registry at the moment of creation. The LSOS (Lean Sovereign Operating System) audit log provides an immutable record of when each pattern was developed, by which crew member, under which ARB. This is the proof that an idea existed before any Crown contract engagement.
BACKGROUND IP PROOF CHAIN:
NP-XXXX registered → fleet-sync/novel-patterns/PATTERN-REGISTRY.md
Timestamp: git commit SHA + date
ARB linkage: developed under ARB-YYY (pre-engagement)
γ₁ anchor: 14.134725141734693 ← cannot be post-dated
LSOS audit: msclo crew record + msi01 gate result
Result: this IP predates the Crown contract. It is background IP.
III. Data Sovereignty on Public Infrastructure
When EOSE fleet nodes operate in TTC stations, they generate operational data: routing decisions, model inference logs, fleet heartbeats, error states. Who owns this data?
- EOSE operational data (fleet health, model performance): EOSE's data. It has nothing to do with TTC's mission. Must be excluded from any MFIPPA access request by explicit contractual language.
- Transit operational data processed by EOSE systems: subject to TTC/Metrolinx ownership but processed under a data processing agreement that limits EOSE's use to the contracted purpose only.
- Derived insights (fleet optimizations learned from transit patterns): the most contested category. Alan's position: anonymized, aggregated insights that do not reproduce personal information are EOSE background IP. The contract must say so explicitly.
IV. The IP Schedule — What Must Be in Every Subcontract
- Schedule listing all EOSE background IP by category (not every NP — categories are enough)
- Definition of "foreground IP" limited to project-specific deliverables
- EOSE license grant to STC/Metrolinx: non-exclusive, non-transferable, project-specific only
- EOSE's reserved right to use foreground IP in non-competing contexts
- Data processing agreement covering all transit data EOSE systems handle
- Survival clause: IP schedule survives contract termination
V. Alan's Formal Statement
The γ₁-anchored proof system is not metadata. It is evidence. Every EOSE novel pattern, every ARB, every engine in the fleet registry is timestamped and linked to a mathematical anchor that cannot be forged or backdated. If the IP ownership of any EOSE technology is ever disputed in a Crown contract context, the LSOS audit log is the primary evidence. Build the IP schedule now. The proof is already there.