Every view is the same model.
Most tools make you choose a format and then keep the others in sync by hand. NexoGraph keeps one graph and renders it five ways — switch the view and nothing is exported, converted or duplicated.
One requirement, five representations — the same model data, not five exports.
Traceability is a graph. Most tools store it in tables.
That mismatch is why coverage analysis is a report you request instead of a thing you look at.
In a document-and-table tool, the link between a stakeholder need and the requirement that answers it is a cell. Following it two hops takes a query someone has to write; following it six takes a specialist and a weekend.
NexoGraph stores the model as a graph from the ground up. A relation is an edge, so traversal is the cheap operation — which changes what you are willing to ask. Impact of a change, orphaned requirements, needs with no coverage, elements with no allocated requirement: these stop being audit exercises and become views you keep open.
Everything else in the product follows from that decision.
Five views, one selection
Every model discipline mounts the same workspace, so there is one set of habits to learn rather than one per module.
Explorer
Tree on the left, attributes and references on the right. Arbitrarily deep packages, inline rich-text editing, and a references panel carrying relations, history and comments.
Table
The same hierarchy as a sortable, filterable grid. Choose which attributes appear on rows; the choice is remembered per feature.
Hierarchy
Containment as a diagram, for when the shape of the model is the question rather than the contents.
SysML
SysML v2 textual notation generated live from the model, with a rendered diagram beside it. No export step, nothing to keep in sync.
Context
A system boundary you can draw on. Drag elements, connect port to port, auto-arrange — the geometry is a view property, the connections are real model edits.
Nothing reaches the shared model until you commit it
Edits land in your browser first and flush in bulk, so typing never waits on the network.
Local-first staging
Your changes are written to local storage as you make them and synced in batches. No round-trip per keystroke, and a dropped connection costs you nothing.
A review you can actually read
The commit dialog groups work as new, edited and deleted, with per-attribute before-and-after values. You write a commit message; the model changes as one unit.
Locks that tell you who
Objects lock when someone starts editing and stay locked until they commit. Everyone else sees the holder's name immediately, and can ping them to release it.
Freeze it, browse it, branch from it
Configuration management that behaves like configuration management, without leaving the tool.
Freeze a discipline or a package
Take a baseline of a whole root or one package. Frozen objects refuse edits — the constraint is enforced by the engine, not by convention.
Read the model as of a date
Switch a workspace to a baseline and the whole tree, every attribute and every relation, shows what it held at that moment.
Check out a new version
Create a new version of a baselined object and carry its live relations with it. Version navigation is built into the workspace.
Typed revision history
Every change is a typed revision — content, re-parenting, relation change, freeze — so history answers what kind of change happened, not just that one did.
Links with meaning, identifiers with rules
Relations come from a curated catalog, so the graph stays interpretable as it grows.
Stakeholders raise needs. Needs are answered by requirements. Requirements are allocated to system elements and constrained by interfaces. Each of those is a named relation type from the metamodel, not a generic link — which is what makes coverage and impact questions answerable rather than approximate.
Identifiers are generated from the metamodel too. Each root and scope carries its own prefix and counter, so a requirement is REQ_48 everywhere it appears, and the prefixes follow your house numbering scheme rather than ours.
Hover for parameters. Select to keep them open.
Requirement
Selected- reqText
- Inhibit DC charging when any cell exceeds 55 °C
- priority
- High
- rationale
- Protect cells from thermal damage
- source
- NEED_12
Connected classes
Stakeholder needrefines intoRequirement
User needrefines intoRequirement
Requirementsatisfied bySystem capability
Atlas drafts the model. You decide what lands.
Not a chat window bolted to the corner of a modelling tool — an agent with the model's own write path and your permissions.
Your edit session
No changes yetNEED_12 / Protect the battery during charging
Monitor cell temperature
Inhibit charging above 55 °C
Resume charging safely
It writes entities, not prose
Ask for a business case and Atlas stages actual stakeholders, needs, requirements and relations into your edit session. They appear in your commit dialog like anything you typed.
It cannot commit
There is no commit tool in its toolset, by design. Every change Atlas proposes passes through the same review you use for your own work.
It has exactly your permissions
Atlas acts as you rather than as a service account. It cannot read a project you cannot read, and it cannot write where you have read-only access.
It reviews to ISO 29148
Ask it to find contradictions, coverage gaps and quality defects. Requirements are checked for being atomic, unambiguous, verifiable, justified and traced.
It drives the interface
Ask to see the goals and Atlas navigates you there and selects the object — the right page, the right view, the right entity.
It listens
Dictate into the composer instead of typing. Useful when your hands are on a diagram and the thought is three sentences long.
Built for more than one engineer
Live over websockets — presence and locks are pushed, not polled.
Presence at four levels
See who is online globally, in the organization, in the project, and on the exact object you have open.
Threaded comments
Discuss any object in place, with mentions, reactions and resolve. Threads follow an object across versions and show which version they were written against.
Notifications that matter
Mentions, replies, resolutions, review requests, finished AI analyses, and lock-release requests — in-app, with an inbox.
Four interface languages
English, German, Polish and Spanish, with the locale carried in the URL.
Evidence, not assertions
Quality and progress are derived from the model itself, so a review starts from data rather than from someone's spreadsheet.
Model consistency checks
Configure project-scoped rules that flag contradictions, broken traces and structural gaps across the model. Run them on demand or let them run overnight; results stream in live, and you can trigger a check from inside the workspace you are already editing.
Work product status reports
Objects created, updated, deleted and moved through lifecycle states, per feature and over time. Engineering progress as a measured quantity instead of a status colour someone chose in a meeting.
Measurement configuration
Choose which change metrics each feature collects for this project, so the report measures what your programme actually tracks rather than a fixed vendor template.
Identifiers on your terms
Set the prefixes generated for objects in each feature, so everything carries your house numbering scheme from the first day and matches the documents around it.
Stakeholder requirements / Thermal management
From draft to approved.
One feature, four work packages. Snapshot: 14 September 2026.
Suppliers are part of the system
Agreement processes live in the same model, under the same permissions, as the engineering work they support.
Supplier management
Maintain the suppliers engaged on a project — profile, classification, contacts, and the items each one supplies — alongside the system those items go into.
Procurement management
Define the items to procure and keep them attached to the parts of the system that need them, so a supply change has a visible engineering consequence.
Open one supplier, not all of them
Individual suppliers and supplied items start invisible and are granted explicitly. One supplier's commercial data can be opened to exactly one team without exposing the rest.
Toward full supplier exchange
RFI, RFP, RFQ, requirement specifications and response matrices extend the same model outward to the people you buy from.
Standards as structure, not as a compliance page
The frameworks below shape the product's information architecture, its metamodel and its exchange formats.
The navigation is the process framework — technical, technical management, organizational and agreement processes, each with its own workspaces.
The requirement quality rules Atlas reviews against, and the shape of the requirement entities themselves.
Every workspace renders its model as SysML v2 text. The domain metamodel is itself a browsable SysML v2 definition library, and a real language server backs the editor.
Import and export requirements with DOORS- and Polarion-class tools. Imports arrive in one reviewable package you commit or abandon as a unit.
Work products, bidirectional traceability and review evidence are first-class model objects, so assessment evidence is a view of the model rather than a document drive.
Item definition, HARA, safety goals and the concept chain — and their cybersecurity equivalents — modelled as connected disciplines rather than parallel document sets.
Variation as a modelling concern: features, variants and configurations defined once in the domain model and bound per product, rather than copied per programme.
Stakeholders, concerns and viewpoints are modelled entities, so an architecture description is generated from the model instead of maintained beside it.
The whole lifecycle, already mapped
This is the product's process map, read directly from the same registry that drives the application's navigation and permissions. Every entry below is a named workspace with its own access level. 137 of them, today.
Technical Processes
101- Business Analysis17
- Stakeholder Definition7
- System of Interest Definition4
- System Definition4
- Architecture Definition4
- Architecture Design3
- Safety Definition11
- Security Definition11
- Communication Design
- Diagnostics Design
- Software Design
- Hardware Design
- Harness Design
- Verification
- Validation
- Transition
- Implementation
- Integration
- Manufacturing Procedures
- Tooling
- Release Management
- System Deployment
- System Handbook
- Operational Monitoring
- Operator Training
- Incident Response
- User Feedback
- Safety Monitoring
- Security Monitoring
- Operational Data
- Software Patches
- Preventive Maintenance
- Corrective Maintenance
- Technical Support
- Field Service
- Retirement Plan
- Decommissioning Records
- Disposal
- Lessons Learned
- Closure Report
Technical Management Processes
11- Project Planning
- Risk Management
- Configuration Management3
- Quality Assurance1
- Measurement Process2
Cross-Cutting SE Methods
4- Modeling and Simulation
- Interface Management1
- Electromagnetic Compatibility
Organizational Processes
8- Lifecycle Model Management2
- Quality Management
- Human Resource Management
- Knowledge Management2
Agreement Processes
13- Acquisition Management11
- Supply Management
Who sees what, and what it cost
Engineering data is rarely open to everyone in the organization. The permission model assumes that.
Permissions per workspace
Every route carries a level — invisible, read or write — per user and per team. Read-only users get the same screens with every write control gone, not a different product.
Grants that inherit sensibly
Levels resolve by nearest ancestor and maximum across a user's teams, so you grant a branch once instead of two hundred leaves.
Instance-level access
Individual suppliers and procurement items default to invisible and are granted explicitly, so one supplier's data can be opened to one team.
Your lifecycle, your states
Define the lifecycle phases of your organization and the state machines its objects move through — draft, reviewed, approved, or whatever your process actually calls them.
AI spend you can audit
Every AI turn is recorded per user, project and surface. Prices are time-windowed and applied on read, so correcting a rate corrects history.
Cost per created entity
Committed objects are counted and split by whether a human or Atlas authored them, which makes the return on AI assistance a number rather than an impression.
Briefly, the parts that matter to you
Self-hostable
Run it in your own environment. Engineering data does not have to leave your network.
One API for everything
The web workspace, the operations console and any integration you build talk to the same backend, with the same permission model.
Built to connect
ReqIF today. Integrations with the PLM, ALM and issue trackers you already run are where this goes next.
Model the system, not the paperwork
Read the documentation for the metamodel, the standards background and the workspace reference — or tell us what you are building and we will take it from there.