Migration and legal notes
How ROST should handle companies arriving from another operating-system framework without overusing protected third-party marks.
Some customers will arrive with experience in EOS, the Entrepreneurial Operating System. ROST can help them migrate their operating data, but ROST should not present itself as an EOS product, EOS-compatible product, certified EOS tool, or substitute copy of EOS materials.
Public-language rule
Use ROST vocabulary in product surfaces:
- Compass
- Responsibility Graph
- Seat
- Charter
- Steward
- Cascade
- Signal
- Friction
- Sync
If a public page needs to mention EOS, do it only to identify the source framework a customer may be migrating from. Keep the mention factual, limited, and accompanied by a non-affiliation statement.
Do not copy
Do not reproduce proprietary worksheets, templates, diagrams, branded meeting agendas, certification language, tool names as product primitives, or long expressive text from third-party materials.
Safe migration framing
Accept user-provided files as input. Translate their concepts into ROST structures. Explain the result in ROST language. Link to this note when a migration flow needs to clarify that ROST is independent and not affiliated with EOS Worldwide.
Migration importers (one upload per artifact)
Leaving another operating tool should be one upload per artifact, not weeks of re-typing. Each importer parses a user-provided CSV export into a validated payload, resolves each record's owner NAME to the seat of that name (an owner matching zero or more than one seat is skipped with a reason — nothing is guessed), then creates the matching ROST object through the same governed write path a human uses.
| Source artifact | Becomes in ROST | Command or flow |
|---|---|---|
| V/TO document | Compass draft for human review | compass.import |
| Scorecard (measurables + numbers) | Signal measurables + trailing readings | signal.import |
| Org chart export | Seats + occupancies + charter seeds | org intake upload (onboarding) |
| Issues list | Friction issues | friction.import |
| To-dos | Tasks (provenance origin_kind:manual) | task.import |
| Rocks | Cascade cycle goals under a company objective | cascade.import |
| Generic OKR export (objectives + key results) | Cascade goals + measurables (informs) + milestone goals | cascade.import_okrs |
The browser migration flow is /migration/ninety: upload V/TO, Scorecard, Rocks, Issues, and To-Dos independently, and use the onboarding org-intake upload for org chart exports. The CLI file surface mirrors the same commands: rost signal import --file scorecard.csv, rost cascade import --file rocks.csv, rost friction import --file issues.csv, and rost task import --file todos.csv. MCP calls pass the parsed arrays directly. Every surface delegates to the same command IDs; there is no UI-only importer.
compass.import accepts extracted V/TO text and creates a Compass draft, never an accepted Compass. friction.import maps priority words to low/med/high/critical (blank defaults to med). task.import keeps a valid YYYY-MM-DD due date when present. cascade.import requires an active cycle and a company objective (auto-selected when exactly one exists in the active cycle, otherwise pass the objective to attach under).
Imports are a human migration action: they require a human actor, write human-confirmed records, and record an append-only provenance row per import. They are idempotent two ways — re-uploading the identical file is a no-op, and within a file an existing matching record (same seat + title, or same seat + summary) is skipped rather than duplicated. A dry run reports counts without writing.
Agent guidance
Agents should not teach EOS as EOS. They should use ROST's method. When a user asks about a migration from EOS, agents may say that ROST can import and translate familiar operating-system artifacts into Compass, Responsibility Graph, Charters, Cascade, Signal, Friction, and Sync.