Design
SCN-01 · Operating conditions
Consider the app, service and physical controller together. Use the scenario and system boundary to examine behavior when connectivity changes.
Systems engineering for engineers and AI agents
Define the system. Build on shared understanding.
Describe what the system must do, how it will be used, and the constraints it must respect. Connect that knowledge to requirements so engineers and AI agents can use it throughout design, implementation, verification, and change.
Account required to start a project. The example is illustrative.
DefineConnectReviewUse throughout engineering
Remote door access
Select an item to inspect its meaning.
- Explored in
- Informs
- Supported by
SW-01 · Software requirement
The app shall display Unlocked only after receiving the controller’s physical unlocked-state confirmation correlated to the current request.
A closer look
Watch the introduction.
A brief introduction to Ellygent. Explore the connected system example at your own pace when you are ready.
Explore the system example →One system, connected knowledge
Define purpose, operation and behavior.
Ellygent is a systems engineering workspace for defining and maintaining connected engineering knowledge. In this example, requirements stay connected to purpose, operating conditions and boundaries.
Purpose and people
Authorized residents need remote access. Residents and access administrators have different responsibilities and expectations.
Operation and boundaries
A request crosses the app, service and door controller. Connectivity can fail. Mechanical access and emergency egress sit outside this example.
Behavior and open decisions
Physical confirmation informs the displayed outcome. Offline behavior remains a recorded question until engineers review and resolve it.
From definition into engineering work
The same understanding carries forward.
Engineers and AI agents can use selected engineering knowledge throughout the work. Ellygent maintains the information that supports these activities; it does not perform them all.
Implementation
SW-01 → SYS-01 · Requirement source
Engineers and AI agents can work from the software requirement and its system-level reason: accepting a command does not confirm that the door unlocked.
Verification
OBJ-01 + SYS-01 · Expected outcome
Use the expected physical outcome and operating conditions to inform verification work. Check the app’s reported outcome against controller confirmation.
Change
DEC-03 · Related information
If offline behavior changes, follow maintained relationships and source notes to investigate the scenarios and requirements that need review.
Inside Ellygent
Develop the definition. Keep it connected.
Author and connect
Develop purpose, objectives, stakeholders, scenarios, boundaries and constraints alongside requirements. Record rationale and questions as understanding develops.
Use AI assistance with review
Request proposals and quality feedback inside Ellygent. Inspect the reasoning, edit the content and decide which changes to accept.
Keep a reviewable record
Discuss requirements with linked comments, inspect traceability and compare saved project versions. Revisit decisions as the system evolves.
For engineers and agents downstream
Read it here. Take the relevant information with you.
Choose the scope and version, inspect the exported information, then supply it to your engineering workflow or AI agent. Refresh your copy when the definition changes.
Explore export, CLI and API workflows →01
Read and inspect
Use the engineering Viewer, relationships and traceability matrix to review recorded information in Ellygent.
02
Download selected content
Share a definition summary or specification export. ReqIF supports requirements exchange; readable exports support review. A summary does not include every requirement and relationship.
03
Query or pull a context package
The Context API and CLI provide selected definition content, requirements and relationships. The package manifest identifies its project, version and export time.
You choose which files or API results to supply to external tools. Their output still needs engineering review.
Engineering depth, where needed.
ReqIF exchange · Saved baselines and version comparison · Requirements quality reviews · Functional Safety analysis
See capabilities and their scope →Safety tools support engineering analysis; they do not establish certification.Practical questions.
No. Start with the information needed for the work ahead. Record unresolved questions and develop the definition alongside exploration, design and implementation. Relationships help keep that evolving understanding connected.
Yes. Author specifications or import supported ReqIF content. Engineers can then add or connect the purpose, scenarios and constraints behind those requirements; an import does not recover missing stakeholder knowledge automatically.
The supported routes are reading in Ellygent, downloading exports, and querying or pulling selected information through the Context API and CLI. You choose what to supply to external agents. A file export is not a native agent integration, and receiving it does not guarantee correct implementation.
Choose a project mode for your work. Foundation supports requirements management; Lite adds capabilities and derivation; Engineering adds upstream system definition. Functional Safety adds safety-oriented analysis. Available steps depend on the mode and enabled modules.
You first create an account and complete the existing account setup flow, then create a project and choose its mode. The public example is illustrative and is not copied into your project.
Start with the system you are working on
Give your engineering work a connected foundation.
Bring what you know. Record what is still open. Develop the understanding as your system evolves.