# Clark Network Operating Model

This document holds the richer operating mechanics behind CLARK's platform model so the core business plan can stay concise.

## Core Principle

CLARK is designed to own the shared layer of the network while keeping regional nodes independently owned and operated.

## Expansion Mechanisms

### Calls for Research

Use structured research commissions to develop new process IP, software tools, and technical methods at the node level.

### Calls for Facilities

Use a formal operator selection process to launch new regional nodes that meet CLARK's requirements for capability, certifications, workforce, and logistics fit.

### Acquisition And Conversion

Acquire or convert existing precision manufacturers into licensed nodes where that produces faster expansion or stronger local credibility.

## Shared Platform Assets

- Intellectual property and process documentation
- Brand system
- Training curricula and certification programs
- Software tools and collaboration infrastructure
- Cross-border logistics coordination
- Node launch and integration methods

## Node Economics

Nodes are expected to remain autonomous operating companies. CLARK participates through fees, minority equity ownership, and contractual rights tied to shared assets.

## IP Model

CLARK owns the shared IP portfolio. Nodes that originate valuable IP may receive participation rights tied to the net licensing income generated by that specific IP.

## Software Layer

Clark software is built to interact directly with the physical spaces where it is deployed and with the tools, machinery, operators, and experts involved in production. Its central purpose is to log, synthesize, and report on facility activity, including the actions of both human and AI agents. CLARK uses the Theia Framework, open-source components, and proprietary products to build Integrated Production Environments that unify business-information flows inside each facility while combining strong on-site security with controlled remote participation.

Beyond the facility, the broader CLARK platform is intended to amplify industry awareness, education, and coordination without violating customer privacy requirements or jurisdictional constraints. The collaboration layer is expected to rely on chat and presence models aligned with XMPP-style standards so production partners, AI agents, and automation services can work in responsive workflows rather than rigid deterministic sequences. CLARK also expects to operate inspectable server infrastructure inside key North American nodes and to manage stored data in ways that preserve immediate owner access.

### Version 1 Scope

#### Core-Now Capabilities

- Facility activity logging for production, testing, maintenance, quality, and training events
- Human and AI agent audit trails tied to workspaces, jobs, and equipment interactions
- Role-based reporting and operational dashboards for owners, operators, and managers
- Theia-based Integrated Production Environments for firmware, test, and production-support workflows
- Secure on-site-first collaboration with controlled remote participation
- Chat, presence, and workflow coordination for production participants, AI agents, and automation services
- Owner-accessible data storage, export, and backup controls inside node infrastructure

#### Later-Phase Capabilities

- Cross-node industry-awareness and benchmarking views that preserve customer confidentiality
- Broader educational and ecosystem-facing reporting layers beyond direct facility operations
- Deeper machine integration across a wider variety of production equipment and building systems
- Automated orchestration that can recommend or execute more of the work-plan evolution across sites
- Third-party inspection portals and richer partner-facing observability surfaces

#### Out Of Scope For Version 1

- A general-purpose ERP replacement
- Full facility digital-twin modeling
- Broad consumer-facing collaboration products
- Deterministic end-to-end factory automation across every process step
- Cross-company data sharing that weakens privacy, ownership, or jurisdictional compliance

### Version 1 Boundary Rationale

Version 1 should stay focused on the operating layer that CLARK uniquely needs in order to prove the first corridor: facility-aware workspaces, trustworthy reporting, auditable human-and-agent activity records, and secure collaboration around production work. CLARK should not try to replace all enterprise systems in early deployments. The product boundary is strongest where software directly improves visibility, accountability, and coordination inside real assembly environments and where that software can be bundled into node licensing.

## Open Questions

- What data model should define jobs, conversations, machine events, and agent actions across nodes?
- Which XMPP-aligned or adjacent messaging architecture best fits CLARK's privacy and inspection goals?
- What minimum offline and local-first guarantees are required inside each facility?
- What participation formula best aligns node innovation with platform economics?
- What governance protections are required without undermining node autonomy?
- Which expansion path should dominate first: Calls for Facilities or acquisition conversion?