That Is A Q
INTERNAL HANDBOOK

Ownership of Work Product

Policy v2.4 Last updated: October 2024 Owner: Legal & Engineering Leadership

All work product created by team members of That Is A Q during the course of employment, contracting, or official engagement is governed by this policy. This document clarifies intellectual property rights, usage guidelines, attribution standards, and compliance requirements across all project types.

📌 Core Principle We build with transparency, respect external licenses, protect client IP, and maintain high standards of documentation and attribution.

IP Assignment & Scope

By default, all work product developed while using company resources, during working hours, or in direct relation to assigned projects is the exclusive property of That Is A Q or its designated client, as outlined in the applicable Master Services Agreement (MSA) or employment contract.

  • Source Code & Repositories: All commits, branches, and CI/CD configurations are owned per project contract.
  • Design Assets: Figma files, UI kits, illustrations, and motion prototypes follow the same assignment structure.
  • Documentation & Runbooks: Internal wikis, API docs, and deployment guides remain company property unless otherwise specified.
  • AI-Generated Outputs: Models, fine-tunes, or prompts developed during paid engagement are assigned per the project's IP clause.

Client vs. Internal Work

Clear separation between client deliverables and internal tooling is mandatory to prevent IP contamination and ensure clean handoffs.

Work Type Ownership Storage/Access
Client Projects Assigned to Client (per SOW) Client org / Mirrored internal archive (read-only)
Internal Tools That Is A Q Company GitHub / Figma / Notion
Shared Components Company (licensed to clients) Q-Design-System repo / Private npm registry
R&D / Experiments That Is A Q Internal sandbox environments
⚠️ Boundary Rule Never mix client-specific business logic with internal reusable libraries without explicit architectural review and legal clearance.

Code & Design Standards

Ownership includes responsibility. All deliverables must meet minimum quality and maintainability thresholds before handoff.

Development Requirements

  • All code must pass CI linting, type-checking, and unit test coverage ≥ 80%
  • Git history must be linear, squashed logically, and contain conventional commit messages
  • Environment variables, secrets, and credentials must never be committed
  • Architecture diagrams and decision records (ADRs) required for complex systems

Design Requirements

  • Components must follow the Q Design System token structure
  • All stylesheets, variants, and auto-layout constraints must be named and documented
  • Exported assets must be optimized, annotated, and paired with handoff notes
// Example: ADR-042 - State Management Strategy
# Title: Use Zustand over Redux Toolkit
# Context: Client X requires minimal boilerplate and fast onboarding
# Decision: Adopt Zustand for client-facing dashboards
# Consequences: +Developer velocity, -Ecosystem maturity vs Redux
# Approved By: Engineering Lead, 2024-09-12

Open Source & Third-Party Dependencies

We actively use and contribute to open source, but all integrations must be vetted for licensing compatibility and security.

  • Permissive Licenses (MIT, Apache 2.0, BSD): Allowed with standard attribution
  • Copyleft (GPL, AGPL, LGPL): Requires Legal review before integration
  • Commercial/Enterprise: Must have valid license tracking in /licenses/manifest.json
✅ Contribution Policy Team members may contribute to personal or public open-source projects outside working hours using personal equipment. Any contribution leveraging company IP or proprietary patterns requires prior written approval.

Attribution & Portfolio Usage

Recognition is part of ownership culture. All work must be properly credited internally, and external portfolio usage follows strict consent protocols.

  1. Internal Credits: Every PR, design handoff, and deployment includes contributor tags via Git/Figma metadata
  2. Client Approval: No case study, screenshot, or code snippet may be published externally without signed Portfolio Release Form
  3. Anonymous References: When client NDA restricts disclosure, use codenames and sanitize data/UI elements
  4. Team Showcases: Quarterly internal demos highlight individual and collective contributions

Compliance & Data Handling

Ownership extends to data security and regulatory alignment. All work product must comply with applicable standards.

  • PII/PHI Data: Never used in dev/staging environments without synthetic substitution
  • GDPR/CCPA: Data processing clauses embedded in all client handoffs
  • Audit Trails: All deployments, design exports, and documentation updates are version-controlled and timestamped
  • Incident Reporting: Any suspected IP leak or unauthorized fork must be reported to security@thatisaq.com within 24 hours