# Capella behavior creation study — 2026-09-10 Codex-9e8r6t /root/palette_finish. Bounded native reference study under the revised PROJECT_GOAL; this is product evidence, not Studio acceptance. ## Environment and limits Used the installed Capella 7.1 executable `C:\Users\User\capella-7.1.0.202606231255-win32-win32-x86_64\capella\capella.exe` through the Computer Use skill and `@oai/sky` only. Root granted exclusive native input and closed its saved Studio instance first. Launch was 18:42 UTC; final save and clean close were 18:56 UTC. Startup/project initialization consumed several minutes and briefly showed Windows Not Responding. No helper/user stop occurred. Fresh `sky.list_windows()` after Alt+F4 confirmed no Capella windows; the input lease was explicitly released to root. Selected actual returned launcher window 4326384 and workbench 3146748. Used new workspace `.local/capella-creation-20260910`, native-created project `Local Behavior Creation`, at 1010 × 760. Existing models were not opened or changed. Screenshots were inspected as Computer Use tool evidence; no separate screenshot archive is claimed. Saved XML provides independent semantic evidence. No Studio production edits, Cargo runs, or unrelated product evaluation. ## Observed creation workflows 1. Project workflow → Operational Analysis → **Define Operational Activities and describe Interactions** exposed three explicit task links: OABD activity breakdown, OAIB activity interaction, and OAS activity scenario. Selecting OAS opened **New Activity Scenario**, with one Name field defaulting to `[OAS] OperationalCapability 1`. Entering `Dispatch response` and accepting opened that scenario. Viewpoint was selected through the named entry point, before naming; no general element catalog or secondary viewpoint picker was required. The project became dirty before the Name dialog was accepted. Saved XML confirms an automatically created OperationalCapability owns the scenario. Cancellation side effects were not tested. 2. Inside the empty OAS, **Activities** followed by a canvas click opened a **Transfer Dialog / Selection Wizard** with an eligible Operational Activities tree, search fields, Available and Selected panes, and transfer arrows. It contained Root Operational Activity in this fresh model. The dialog was canceled. **Activity**, then a canvas point, instead created a new activity and its visible lifeline without leaving the scenario. Saving confirmed distinct Activity and InstanceRole identities and the representedInstance reference. The new activity also acquired an explicit capability involvement. This is stronger evidence than a tooltip alone for local missing-source creation. Reusing an existing source through the transfer dialog was observed up to selection UI, not completed in this pass. 3. System Analysis → **Refine System Functions, describe Functional Exchanges** exposed SFBD functional breakdown, SDFB functional dataflow, and FS functional scenario. FS opened **New Function Scenario** with default `[FS] Capability 1`; accepting opened a functional scenario. Its palette contained **System Function**, **Functions**, and functional exchange tools, corresponding to the selected function viewpoint. XML confirms kind FUNCTIONAL under a new Capability. Component/entity/interface viewpoints were not exercised here. 4. SDFB opened a Name dialog defaulting to `[SDFB] Root System Function`. Its palette exposed Functions, Functional Exchanges, and Functional Chains as insertion tools. The Functions tooltip explicitly distinguishes graphical removal from deleting a semantic function. Accelerator choices included Elements from Scenario and Functional Chain Elements; these were read, not executed. 5. From that dataflow diagram, **F8 / Show in Project Explorer** revealed the root System Function. Its context menu **Add Capella Element → Functional Chain** created `FunctionalChain 1` immediately. Renamed it `Dispatch chain`. On the chain, **New Diagram / Table → Functional Chain Description** opened a second Name dialog with default `[SFCD] Dispatch chain`; accepting opened the chain workspace. Thus the exercised path involved separate semantic creation, naming, and first representation creation. It was an owner-filtered menu, not a global type catalog, but still a substantial detour from the canvas. 6. In SFCD, **Function** under Involvements had the tooltip “Creates a new Involvement Function referencing the selected Function.” A canvas point opened **Select a Function to involve in Dispatch chain** with a filtered System Functions tree/search. There was no visible Create new source action in this picker. Canceled without adding an involvement. Other local tools included Exchange, Exchange and Function, AND, AND Construct, Sequence Link, and Function on Sequence Link. Their execution was outside this timebox. ## Saved evidence Files remain in `.local/capella-creation-20260910/Local Behavior Creation/`. | Saved record | Identity / meaning | | --- | --- | | OperationalCapability 1 | `69d805a8-8a2f-4218-88f0-566bf0923e7f` | | Dispatch response | `b8de31f0-378e-423a-855c-eba3551ca645`, INTERACTION, owned by that capability | | OperationalActivity 1 | `30f0691c-a6d7-422d-abf2-fa1746e1b92b` | | InstanceRole | `f1b80b8b-7770-4b9d-aad7-0eb8da9be902`, represents that activity | | Capability involvement | `b9a781c1-ee73-49e0-a6ec-10d838f2b613`, involved activity reference | | Root System Function | `92c6eca2-6fcb-43d9-baa1-bd7b26e633f0` | | Dispatch chain | `4ae2255c-4c80-4173-b7f4-b5da43fafe97`, FunctionalChain owned by root function | | Capability 1 | `41ef1a86-f1b8-4c62-9ad3-19357d622b04` | | [FS] Capability 1 | `693543b9-e3f4-4fa1-a44c-efc5683f9d14`, FUNCTIONAL under Capability 1 | Final SHA256: - `Local Behavior Creation.capella`: `829f7faa99907c1efd826c79289bd2a7f795cdab557ec91f3a7e13ddb93417e1`. - `Local Behavior Creation.aird`: `354a74cfac5abe29188f3b644e79f84af6136fc67f968be43b4f4c663c0392a8`. ## Proposed Studio application, distinguished from observations Preferred alternative: one compact **New behavior** entry with a small set of task choices; show only relevant name, viewpoint and ownership/context fields. For a scenario, explicitly distinguish OA activities/entities and SA functions/components. A task entry can preselect the appropriate viewpoint, but the choice must stay visible. Starting a named process/chain should open its authoring workspace directly after one validated command batch. A first view can be explicit where the model separates it. Do not copy Capella's implicit capability creation or its owner hierarchy into Studio: Studio's admitted ownership and optional semantic context are authoritative. Within scenario or chain authoring, a compact **Use existing / Create new** source choice can preserve work context and filter candidates by layer and viewpoint. The existing-source action must state that it creates a lifeline or involvement referencing the source. New source creation should be explicit about the source type and valid owner, preserve the pending authoring intent, and return directly to it. Capella's exercised OAS provides evidence for this local creation path; adding it to the chain picker is a proposed improvement. A viable lower-complexity alternative is a contextual **Create missing source** action that suspends and restores the current draft using the existing source editor. It avoids duplicating field editors but requires reliable focus, raw draft recovery and exact cancellation/history behavior. A single searchable global command catalog remains useful for expert discovery; making it the only creation route would retain the detour observed in current Studio. Key findings were delivered directly to /root/release_audit while that worker owned `behavior/creation.rs` and tests. OA process creation itself, component viewpoints, completed source reuse, chain involvement persistence, and recovery/ Undo/Redo were not exercised in this bounded study; do not infer their success from these observations. The current Studio workflow still requires its own automated and native acceptance.