Engineering records you can follow
Studio keeps what a team knows about a system as records rather than loose files: each one with a code, an owner, a lifecycle, a revision history and explicit links to the records around it. A Development gives them their scope.
A clear scope for every piece of context
A Development is the solution you engineer: a product, a release or a project. It has a responsible person, members, a process and a timeline. Its records, traces and references stay inside it, so its context has a boundary you can reason about.
- Tabs for the business model, requirements, process, change requests, readiness, baselines, quality, knowledge, code and databases
- Traceability gaps and missing work products on the overview
- Visibility follows membership: people see the Developments they belong to

Every record has a code and a history
Business actors and rules, use cases, requirements, decisions, risks, standards, evidence and work products are records with a code (REQ-0001, DEC-0003, RSK-0002), an owner, a state and revisions. Diagrams, test cases, tasks, repositories and databases are first-class records too.
- Lifecycles with explicit transitions, from draft to approved
- Every revision kept, with who changed it and a log message
- Baselined content is never edited in place: a change creates a new revision
- Write
[[REQ-0001]]anywhere and it becomes a link, with “Mentioned in” on the other side

Relationships are records too
A trace is an explicit, typed and directed link between two records, such as derives from, implements, verifies, mitigates or supersedes. It can carry a rationale and it has revisions of its own. Studio never infers traces, so you can rely on them in a review or an audit.
Typed
Two dozen trace types ship by default, each with an inverse label and rules about what may link to what.
Across modules
Requirements, decisions, diagrams, tests, tasks, articles, repositories and databases can all be ends of a trace.
Access-aware
A trace never reveals a record you are not allowed to see, not even its title.
Baselined
Baselines capture the exact revisions of records and of the traces between them.
Know what was agreed, and when
Revisions answer who changed what. Baselines answer what was in force: Studio takes one when a milestone is reached, and you can take your own at any time. A revision held by a baseline is never deleted, and change requests record who decided, when and why.
- Decisions recorded with their rationale and the alternatives considered
- Change requests linked to the records they impact
- Evidence of verification attached to the run that produced it

Discuss any record, attach anything
Each record carries its own discussion panel with private attachments: the requirement, the test run, the database, the article. The conversation that led to a decision stays next to the record it is about, instead of in a chat thread nobody finds six months later.
- Rich text with links to other records
- Attachments stored privately, visible only to who can see the record

Each role gets the view it needs
Analysts
Capture business actors, use cases, rules and requirements, and see what is still unapproved.
Architects
Record decisions with their rationale, and keep BPMN and UML models next to the requirements they serve.
Process owners
Run Developments through phases and milestones with advisory readiness checks and change control.
Testers & QA leads
Design plans, execute runs step by step, record evidence, report issues, show coverage.
Team leads
Coordinate work on boards, split it into subtasks, follow time spent against estimates.
Developers
Find what a feature should do, why, how it is tested, and read the code and the schema next to it.
My work, my tasks, my runs
Everyone starts from their own queue: the activities assigned to them, the current iterations of their Developments, change requests waiting for a decision, their tasks, their timesheet and the test runs they have to execute.
People work in the Studio workspace, an interface designed for engineering work, not a CMS back office.
