OSOS / Omega — User Documentation

1. Document Control & Version History

Documentation is provided for every release of OSOS/Omega, ensuring historical versions remain accessible.

Current version: v0.9 Pre-launch

How to access earlier versions of this documentation: Simply select a version from the list below to view the documentation as it was published at that time. By default, you are currently viewing the latest version.

Published versions:

• v0.9 Pre-launch — 2026-04-14 — Initial documentation covering access control, traceability framework, and AI-augmented engineering.

---

2. Access Control & Identity Management

The tool has two independent levels of access control: Organization Level (who is part of a company workspace) and Project Level (who can do what inside a specific project).

2.1 Organization Level

Company Admin

• Manages the list of members in the company workspace.
• Invites new members and removes existing ones.
• Controls the company's subscription and billing.
• Has access to every project inside the company, regardless of project-level role assignments.

Company Member

• Has a general seat in the verified company workspace.
• Can see the list of projects their Company Admin has granted them access to.
• Cannot invite new members or change the subscription.

2.2 Project Level

Project Admin

• Configures project-specific workflows (e.g. categories, templates, approval rules).
• Assigns Project Team Members to the project and sets their role.
• Is the only role (besides Company Admin) that can change project-level configuration.

Project Team Member

• Has operational access to the project: can view, create, edit, and approve requirements.
• Can use the traceability features and work with AI-augmented modules.
• Cannot change project configuration or assign other users.

---

3. Traceability Framework (ASPICE 4.0 Compliance)

Traceability is the core of any safety-relevant development process. OSOS / Omega provides four traceability dimensions, each serving a different audit or engineering need.

3.1 Version Traceability

• Detailed change log per item. Every modification to a requirement, test case, or other project item is recorded with timestamp, author, and the exact before/after values of each changed field.
• Full project state reconstruction (Snapshots / Baselines). You can reconstruct the complete state of the project — every item, every link, every approval status — as it was at any point in history. This is the foundation for audit evidence ("what did the project look like on the day of release?").
• Each reconstructed snapshot is strictly read-only. You can browse the snapshot, search within it, and follow links between items, but nothing can be modified.

3.2 Horizontal Traceability

• Links requirements to their corresponding test cases. The tool shows, for each requirement, which test cases verify it and whether those test cases currently pass.
• Coverage checks. A requirement without an assigned test case is flagged. A test case not linked to any requirement is flagged. This supports audit questions like "are all System Requirements covered by tests?".

3.3 Vertical Traceability

• Links requirements across hierarchy levels. Stakeholder Requirements → System Requirements → Component (Hardware / Software) Requirements. Each level derives from the one above and is linked explicitly.
• Derivation coverage. For each System Requirement, the tool shows which Stakeholder Requirements it was derived from, and which Component Requirements were derived from it in turn.

3.4 End-to-End (E2E) Traceability

• Complete linkage from Customer Requirements (ASPICE process SYS.1) down to Final Validation (ASPICE process VAL.1).
• Combines Vertical and Horizontal traceability into a single chain: every Customer Requirement can be traced to a specific Final Validation result, through the intermediate System, Component, Integration, and Test steps.

3.5 Human Approval Traceability

• Verification Evidence. To comply with ASPICE 4.0 requirements for work product verification (e.g., SYS.2.BP6 - Verify System Requirements), OSOS / Omega maintains a dedicated approval trail. It records exactly which human expert reviewed and authorized an AI generated item.

---

4. AI-Augmented Engineering

OSOS / Omega uses AI to assist the user — not to replace them. Every AI-generated artefact is a proposal that must pass through a human review and approval step before it becomes part of the project.

4.1 The Human-in-the-Loop Principle

• The AI generates proposals (requirements, test cases, links, analyses).
• A human reviews, edits if needed, and formally approves each proposal.
• Only approved items are counted in traceability coverage and audit evidence.
• The tool never merges an AI proposal silently. Every approval is recorded in the change log with the approver's identity and the timestamp.

This principle holds across every AI module listed below.

4.2 AI Generation Modules

Customer Requirements

• The tool derives Customer Requirements from two sources: (a) documents the user uploads (PDF, Word, plain text) and (b) free-form chat input describing the product context.
• Each generated Customer Requirement includes a reference back to the source sentence or paragraph so the user can verify the derivation.

System Requirements

• The tool derives System Requirements from approved Customer Requirements.
• Each System Requirement is explicitly linked to the Customer Requirement(s) it was derived from, feeding the Vertical Traceability chain.

Component Requirements

• The tool derives Component Requirements from approved System Requirements, splitting by hardware vs software scope.
• Each Component Requirement is linked to its parent System Requirement and to the target component (hardware module or software module) it applies to.

Test Cases

• The tool derives Test Cases from approved requirements at any level (Customer, System, or Component).
• Each Test Case is linked to the requirement it verifies, feeding the Horizontal Traceability chain.

---