Skip to content

Constraints and Separation Memo

Status

  • Authored: 2026-05-08
  • Owner: project founder (sole)
  • Binding while the author is employed by the Employer / any of its group entities ("the Employer").
  • This memo overrides anything in CLAUDE.md or any other doc in this repo when in tension.

Purpose

The author intends to own this product personally and independently of the Employer. The author is concurrently employed by the Employer under a contract with broad IP, confidentiality, exclusivity, and conflict-of-interest clauses. This memo exists to: - Minimise the risk that any artifact produced here vests in or is claimed by the Employer under the employment contract. - Prevent accumulation of an evidence trail that links the product to Employer resources. - Produce, in parallel, an evidence trail of independent development that future-you can point to.

This memo defines the operational discipline that governs this project's development. Its purpose is to ensure independent provenance and clean separation, not to provide legal interpretation.

Relevant employment-contract clauses (clause structures of this kind are common in AU full-time employment contracts): - 4.3(j) — exclusivity of time and attention to the Employer during employment. - 18.1 / 18.3 — conflict of interest; full-time employees generally cannot take Outside Projects. - 19.2 / 19.3 — confidentiality, defined to include concepts, ideas, know-how, supplier terms; no time limit. - 20.1 / 20.2 — IP vesting "in the course of your employment, whether created during business hours or not." - 22 — active workplace surveillance. - Schedule One — post-employment restraints (cascading restraint area and period).

Refer to the original signed contract directly when in doubt. Do not summarise from memory. The contract is intentionally not committed to this repo.

Scope

  • Applies during employment.
  • Confidentiality and supplier-data rules continue post-employment.
  • Most other rules relax post-employment but should not be relaxed retroactively to past artifacts.

Hard rules — Resources

  • No Employer hardware, network, account, license, cloud, software, peripheral, or any other Employer resource touches this project. Ever.
  • Personal hardware only. Personal home network or personal mobile data only.
  • Personal GitHub, personal Anthropic / Claude Code account, personal email — never linked to any Employer identifier.
  • Do not access this repo, this Claude session, personal product email, or any project artifact from an Employer device, Employer network, or while logged into an Employer account.
  • Includes mobile devices on Employer Wi-Fi. Treat the office network as poisoned.

Hard rules — Time

  • No work on this project during Employer working hours.
  • Lunch breaks count as Employer working hours.
  • Sick days count as Employer working hours.
  • Annual leave does not count as working hours.
  • Commit and activity timestamps should clearly fall outside Employer working hours.

Hard rules — Data

  • No Employer-accessed supplier data is used in any form, at any phase: dev, test, sample, demo, screenshots, mental reference, or "just to check the shape."
  • Allowed data sources:
  • Synthetic data generated from scratch.
  • Public data from supplier/distributor websites or public retailer catalogs, accessed via personal devices outside work hours.
  • Data provided with explicit, documented permission by the unrelated customer-zero connection.
  • Every dataset added to the project must have a provenance.md entry: source URL or person, date acquired, method, why it's safe.

Hard rules — People

  • Do not discuss this project with any Employer colleague, manager, supplier rep, or anyone in the Employer's commercial ecosystem. Includes informal social contexts.
  • Do not approach any Employer supplier or client in connection with this project, even via warm intro.
  • The unrelated customer-zero connection must have no commercial relationship with the Employer / its group. Confirm before involvement.
  • No public posts about this project from any account or device associated with the Employer.
  • No public posts about this product at all while employed (see "Forbidden activities").

Hard rules — Code and content

  • Do not reuse code, schema, queries, design, documentation, diagrams, naming, or any other artifact from any in-house project produced for the Employer.
  • Do not share that in-house repo or its contents with any third party including AI assistants.
  • Do not transcribe in-house concepts into this project from memory.
  • This project's code and design must be derivable from: public knowledge + general skill + the unrelated connection's input.

Provenance hygiene — building the evidence trail FOR independent development

The goal is not just to avoid Employer resources but to produce, in parallel, evidence that this work was independent. - Personal GitHub from day one. Never on Employer infrastructure, never under an Employer email. - Document research sources in-repo: link, date, why this source matters. - Decisions logged as decision memos in docs/decisions/ referencing public / independent sources only. - Commit messages must be free of Employer-specific allusions (no "fix the supplier-X edge case"). - Keep a dated log of when major artifacts were produced, on what device, in what timeframe — sufficient to reconstruct an independent timeline if ever asked.

Knowledge boundary — the litmus test

Before using any specific fact, ask in order: 1. "Did I learn this specifically through the Employer?" Employer-specific processes, supplier-specific relationships, internal data shapes, internal tool architecture, customer info → do not use. 2. "Could I have learned this from public sources, general industry literacy, or the unrelated connection?" → OK, but document the public source. 3. "Is this general programming, SaaS, or PIM knowledge?" → free to use.

If unsure, treat as Employer-derived.

Definitely Employer-derived (do not use)

  • Specific supplier data shapes seen at the Employer.
  • Specific supplier email patterns or portal designs encountered through the Employer.
  • The Employer's POS / ecom / ERP configuration.
  • The Employer's product taxonomy.
  • The Employer's pricing, margin, or commercial terms.
  • Employer colleagues' opinions, names, observations.
  • Internal in-house tool architecture, schemas, code, naming, design decisions.

Safe to use

  • The general industry-known fact that AU music retail has fragmented supplier data quality.
  • Public information from supplier / distributor websites.
  • Public information from competing retailers' product pages.
  • General PIM / catalog data engineering literature.
  • Knowledge shared by the unrelated connection, with their permission.

Surveillance assumption

  • Assume Clause 22 is active and that anything touched on an Employer device or network is logged indefinitely and discoverable.
  • Even reading a public article about PIM on an Employer laptop creates a small evidence trail. Don't.
  • Assume any work-issued mobile is surveilled.
  • Assume that surveillance logs survive employment, in case of later dispute.

Customer-zero connection rules

General

  • The customer-zero connection must have no commercial relationship with the Employer / its group.
  • Their participation must be voluntary, documented, and on their initiative or yours-via-personal-channels.
  • Use of their data requires explicit permission, ideally written.
  • Do not cross-reference their data with Employer-derived knowledge — this re-contaminates a clean source.
  • Lead with letting them describe their pain to you first, before describing your own framing of the problem. Your framing may be characterizable as Employer-derived under Clause 19.3.

Named customer-zero: Global Music Imports (GMI)

  • Co-founders: Reece Specis and Greg Sher. Founded 2025. AU.
  • Relationship: pre-existing personal connection with co-founder. Not formed via Employer work.
  • Confirmed as of 2026-05-08: no supplier relationship between GMI and the Employer / its group; no brand overlap between GMI's catalog and the Employer's catalog.
  • Engagement scope while employed:
  • Permitted: data sharing for product build, design-partner feedback, problem-framing conversations.
  • Forbidden: introductions to other retailers/suppliers, sales help, marketing collaboration, public association with the project, joint outreach.
  • Engagement scope post-employment:
  • Sales help, intros, and broader collaboration may be reconsidered, subject to Schedule 1 post-employment restraints (review at the time).
  • Data sharing rules:
  • Data must be GMI's own to share. Not data shared with GMI in confidence by their own suppliers, customers, or partners without their explicit say-so.
  • Documented permission required: what data, when shared, on what understanding.
  • No data referencing GMI's commercial relationships outside of what GMI explicitly authorises.

Activities permitted while employed

  • Reading public product-strategy / PIM / industry literature on personal devices.
  • Building strategy and discovery artifacts in this repo using only non-Employer-derived inputs.
  • Building thin-wedge code on personal hardware, in personal time, using synthetic or unrelated-connection data.
  • Conversations with the unrelated customer-zero connection.
  • Drafting (not publishing) positioning, naming, branding.

Activities forbidden while employed

  • Any public launch, soft launch, or beta.
  • Outreach to retailers, suppliers, distributors, or industry contacts other than the unrelated connection.
  • Any commercial activity: taking money, signing contracts, registering an ABN tied to this product, or anything else that constitutes "engagement in another business" under Clause 18.1(a).
  • Posts on industry forums, FB groups, LinkedIn, Twitter, Reddit, or HN about the product.
  • Any indexed public web presence — even a quiet landing page leaves footprint.

Decision tests for ambiguous cases

When unsure, run all four: 1. Discoverability test. If a dispute arose tomorrow and everything was subpoenaed, would this decision survive? If you'd hesitate, don't. 2. Provenance test. Can you point to a clean independent source for this knowledge or asset? If no, don't use it. 3. Clean-room test. Could a stranger with your general skills, no employment at the Employer, and access to public data + the unrelated connection have produced this? If yes, fine. If no, suspect. 4. Asymmetric-downside test. What do you gain if you're right it's safe? What do you lose if you're wrong? When the downside dwarfs the upside, choose conservative.

Review triggers

Re-read this memo: - Before starting any new artifact or major doc. - Whenever tempted to bend a rule for convenience. - After any change at the Employer (role change, manager change, audit, etc.). - Monthly minimum.

Revision triggers

Update this memo when: - Employment status changes (resignation, termination, role change). - Customer-zero connection facts change. - Legal advice updates the analysis. - A new ambiguous case is resolved and the resolution is worth encoding.

Suggested next step

With this memo in place, the next artifact is the customer-zero target profile, written using only information from the unrelated connection and public sources.