Preserve native authoring evidence and compared semantic contracts

PROJECT_GOAL.md

@@ -608,9 +608,9 @@ Focus on making the application modern, extensible, intuitive and easy to use. W
 
 Try to address all known problems / downsides of the original ARCADIA Capella software.
 
-Version 1 MVP in the form of working Operational Analysis layer is done.
-Version 2 MVP in the form of working Operation Analysis + System Analysis is done.
-You should make the 1st release version of the project with fully feature complete Operation Analysis + System Architecture, according to this application specification.
+Version 1 MVP in the form of working Operational Analysis layer is done.
+Version 2 MVP in the form of working Operation Analysis + System Analysis is done.
+You should make the 1st release version of the project with fully feature complete Operation Analysis + System Architecture, according to this application specification.
 Remaining ARCADIA layers will be added in future releases.
 
 Transitioning of model elements between layers (in both directions) should be easy and intuitive.
@@ -623,19 +623,19 @@ You should implement most of the ARCADIA semantics, while adressing original ARC
 
 The original ARCADIA Capella UI is very bloated, clunky, unintuitive and hard to use. In addition, it lacks a number of quality of life features. You should at all cost avoid making the same mistakes as the developers of the original ARCADIA Capella
 
-You should explore the functionality & UI of the original ARCADIA Capella to take the most useful and powerful ideas from it. While making them modern, easy to use and understand
+You should explore the functionality & UI of the original ARCADIA Capella to take the most useful and powerful ideas from it. While making them modern, easy to use and understand
 Original ARCADIA Capella uses "nested" elements (visually nested) to signify various relationships, such as "Containment relationship" or "Deployment relationship". Instead of using visually noisy arrows / graph edges. I pretty much like this approach and want to see something similar to it in this application
 
 To explore the original ARCADIA Capella UI & semantics you may use web resources / web search / official and community docs. Or open the original ARCADIA Capella installed on this desktop machine for exploration
 
-Your second, parallel, goal is to create a textual representation for ARCADIA, similar to SysML v2. So a user can either edit a system model using UI (graphical representation) or text. Both graphical and textual representations should be fully equivalent and have full parity. You may take inspiration from SysML v2. Both graphical and textual representations should have one overarching, concrete, unambiguous spec in reST format, similar to SysML v2 strictness
-The application should support both forms of editing
-The textual representation should be easily editable and understandble for both humans and AI
-The textual representation should be easily handled by version control tools such as Git
-The underlying semantics of the textual / graphical representation should support traceability of various development artifacts (for example - code, CAD files, electrical schematics, Docx files and anything in between)
+Your second, parallel, goal is to create a textual representation for ARCADIA, similar to SysML v2. So a user can either edit a system model using UI (graphical representation) or text. Both graphical and textual representations should be fully equivalent and have full parity. You may take inspiration from SysML v2. Both graphical and textual representations should have one overarching, concrete, unambiguous spec in reST format, similar to SysML v2 strictness
+The application should support both forms of editing
+The textual representation should be easily editable and understandble for both humans and AI
+The textual representation should be easily handled by version control tools such as Git
+The underlying semantics of the textual / graphical representation should support traceability of various development artifacts (for example - code, CAD files, electrical schematics, Docx files and anything in between)
 The textual representation editor should have syntax highlighting and linting
 
-The project should also have a backend server / service that you can deploy. The backend server purpose is to give programmatic access to stored system models. So, there also should be a clear REST API for querying, editing and working with models. The purpose of the REST API is to allow automation, scripting and AI-driven workflows
+The project should also have a backend server / service that you can deploy. The backend server purpose is to give programmatic access to stored system models. So, there also should be a clear REST API for querying, editing and working with models. The purpose of the REST API is to allow automation, scripting and AI-driven workflows
 An example could be - writing custom plugins for various domain specific software (version control software, CAD software etc...) to establish traceability between development artifacts and a system model
 
 The desktop application should contain built-in guide / help / tutorial with clear and concise info on modeling concepts, underlying semantics, common modeling scenarios and application features / how to use the app. It should be easy to navigate and explore
@@ -655,6 +655,15 @@ Requirements:
 - Strong, standardized specification.
 - Strong, standardized API.
 
+#### Textual notation
+
+Requirements:
+
+- Should not have visual noise and clutter.
+- Should have means to reduce cognitive load when developing system models.
+- Should be easily editable by humans. And AI agents.
+- System engineers should be able to easily develop system models (both big and small) using textual notation only.
+
 ### UI
 
 The focus should be on reducing system engineer's cognitive load when creating / working with a system model. Regardless of the model size (big or small).