# Failure to flag errors from Syside - An occurrence, item or part must be typed by occurrence definitions. - Duplicate of inherited member name 'self' **URL:** \ **Category:** Bug Reports\ **Created:** [September 16, 2026, 5:08pm UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578 "2026-09-16T17:08:18Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![Richard\_Wallace](https://yyz2.discourse-cdn.com/flex008/user_avatar/forum.sensmetry.com/richard_wallace/32/307_2.png) [@Richard\_Wallace](https://forum.sensmetry.com/u/Richard_Wallace)\ **Post date:** [September 16, 2026, 5:08pm UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/1 "2026-09-16T17:08:18Z")
I’ve noticed many semantic issues with Syside. Here is one that didn’t show up, which is insidious. Given the specification: ```auto //** * To fulfill the Return-to-Home (RTH) automated flight management requirements specified in * Requirement 8.1.1 (All-Weather Runway Operations - Failsafe System), we must model a deterministic * state machine. The system must automatically trigger RTH upon encountering signal loss, a critical * sensor failure, or when the battery charge drops below 20%. * * In SysML v2 (Release 2026-03), flight management logic is represented using a state def block * driven by conditional if expressions evaluating safety thresholds. */ package 'Autonomous Emergency Management' { private import ScalarValues::*; private import Quantities::*; private import ISQ::*; private import SI::*; /* ========================================================================= * SECTION 1: EMERGENCY METRIC AND LINK MONITORING DATA SCHEMA * ========================================================================= */ public attribute def Failsafe_Telemetry_Frame { doc /* Sensory monitoring data structure continuously evaluated by the failsafe state machine. */ attribute batteryChargePercentage : Real; // Expressed from 0.0 to 100.0 attribute commandLinkLostDuration : TimeValue; attribute hasCriticalSensorFailure : Boolean; } /* ========================================================================= * SECTION 2: FAILSAFE STATE MACHINE SPECIFICATION * ========================================================================= */ public state def Autonomous_RTH_Lifecycle { doc /* Automatically triggers and controls Return-to-Home trajectory profiles per Req 8.1.1 failsafe criteria. */ // Inbound parameter mapping active aircraft metrics into the conditional expressions in item systemHealth : Failsafe_Telemetry_Frame; // --------------------------------------------------------------------- // STATE: Nominal Mission Profile Execution // --------------------------------------------------------------------- state nominalMissionExecution { doc /* System operates normally, executing pre-programmed 3D waypoint navigation lines. */ } // --------------------------------------------------------------------- // STATE: Command Link Interruption Buffering // --------------------------------------------------------------------- state commandLinkLostTransient { doc /* Buffers transient command link drops. Executes an un-jamming route for up to 15 seconds per Req 8.1.6. */ entry action executeUnjammingRoute; } // --------------------------------------------------------------------- // STATE: Active Return-to-Home (RTH) Trajectory // --------------------------------------------------------------------- state activeReturnToHome { doc /* System overrides normal routing to autonomously guide the aircraft back to the home waypoint. */ state ascendingToSafeAltitude { doc /* Climbs to predefined minimum safe altitude clearance plane. */ entry action commandClimbPower; } state transitToHomeWaypoint { doc /* Flies directly toward the home coordinates using pre-programmed autonomous flight logic. */ entry action engageHomeNavigationTrack; } state automatedRecoveryLanding { doc /* Executes autoland sequence on the wet/snowy runway utilizing automated ABS traction control. */ entry action deployLandingGearAndABS; } // Standard nested entry path configuration entry; then ascendingToSafeAltitude; // Internal sequencing within the RTH sub-states transition first ascendingToSafeAltitude then transitToHomeWaypoint; transition first transitToHomeWaypoint then automatedRecoveryLanding; } // --------------------------------------------------------------------- // STATE MACHINE CORE TRANSITIONS // --------------------------------------------------------------------- entry; then nominalMissionExecution; // 1. Transition to short-term un-jamming buffer state upon losing command link encryption frame updates transition first nominalMissionExecution if systemHealth.commandLinkLostDuration > 0.0 [s] then commandLinkLostTransient; // 2. Recovery transition if link is restored within the 15-second grace window transition first commandLinkLostTransient if systemHealth.commandLinkLostDuration == 0.0 [s] then nominalMissionExecution; // 3. Escalation to full RTH if command link loss duration exceeds the 15-second mandatory threshold (Req 8.1.6) transition first commandLinkLostTransient if systemHealth.commandLinkLostDuration > 15.0 [s] then activeReturnToHome; // 4. Instant RTH activation from critical internal failures (Battery under 20% or sensor failure) transition first nominalMissionExecution if systemHealth.batteryChargePercentage < 20.0 or systemHealth.hasCriticalSensorFailure then activeReturnToHome; } /* ========================================================================= * SECTION 3: SYSTEM HARDWARE DESIGN INTEGRATION * ========================================================================= */ public part def Flight_Management_Computer { doc /* Autopilot hardware node hosting the real-time safety lifecycle execution loop. */ // Active data monitor instance in local scope item flightHealthMetrics : Failsafe_Telemetry_Frame; // Instantiating the validated state behavior directly inside the hardware scope state failsafeSupervisor : Autonomous_RTH_Lifecycle { in item systemHealth = flightHealthMetrics; } } } ``` The following lines are flagged errors by the OMG Eclipse editor for Rel. 2026-03 - An occurrence, item or part must be typed by occurrence definitions. - Duplicate of inherited member name ‘self’ Lines 36, 118, and 122. The correction is to use “attribute” and not “item” The Syside version is 0.10.3 The corrected lines are: | Line | Statement | | --- | --- | | 36 | **in** **attribute** systemHealth : Failsafe\_Telemetry\_Frame; | | 118 | **attribute** flightHealthMetrics : Failsafe\_Telemetry\_Frame; | | 122 | **in** **attribute** systemHealth = flightHealthMetrics; | V/r @Richard_Wallace ---
**Author:** ![Daumantas](https://yyz2.discourse-cdn.com/flex008/user_avatar/forum.sensmetry.com/daumantas/32/19_2.png) [@Daumantas](https://forum.sensmetry.com/u/Daumantas)\ **Post date:** [September 17, 2026, 6:15am UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/2 "2026-09-17T06:15:13Z")
> [@Richard\_Wallace](#): > > - An occurrence, item or part must be typed by occurrence definitions. Specification does not have this constraint. The closest I can find are: > `checkOccurrenceUsageSpecialization` > > An OccurrenceUsage must directly or indirectly specialize Occurrences::occurrences from the Kernel > Semantic Library. > > ```plaintext > specializesFromLibrary('Occurrences::occurrences') > > ``` > `checkItemUsageSpecialization` > > An ItemUsage must directly or indirectly specialize the Systems Model Library ItemUsage items. > > ```plaintext > specializesFromLibrary('Items::items') > > ``` > `checkPartUsageSpecialization` > > A PartUsage must directly or indirectly specialize the PartUsage Parts::parts from the Systems Model > Library. > > ```plaintext > specializesFromLibrary('Parts::parts') > > ``` Howevere, these are semantic (`check`) constraints which are automatically applied by Syside. > [@Richard\_Wallace](#): > > - Duplicate of inherited member name ‘self’ Seems to stem from the invalid typing by attribute and implicit subsettings. Inherited name distinguishability across inheritance branches is not yet implemented in Syside. ---
**Author:** ![Richard\_Wallace](https://yyz2.discourse-cdn.com/flex008/user_avatar/forum.sensmetry.com/richard_wallace/32/307_2.png) [@Richard\_Wallace](https://forum.sensmetry.com/u/Richard_Wallace)\ **Post date:** [September 17, 2026, 2:02pm UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/3 "2026-09-17T14:02:01Z")
@Daumantas, Thank you for your analysis. The bug report is to document Syside and OMG evaluation of this specification. While the syntax allows the item/attribute statements, the semantics do not allow for this. Your last statement confirms that 0.10.3 is not quite there. I’ve read in the forum that 0.11.x is coming. I’ll upgrade and try again when Syside 0.11.x is available. V/r, @Richard_Wallace ---
**Author:** ![Daumantas](https://yyz2.discourse-cdn.com/flex008/user_avatar/forum.sensmetry.com/daumantas/32/19_2.png) [@Daumantas](https://forum.sensmetry.com/u/Daumantas)\ **Post date:** [September 17, 2026, 2:16pm UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/4 "2026-09-17T14:16:40Z")
> [@Richard\_Wallace](#): > > While the syntax allows the item/attribute statements, the semantics do not allow for this. Is this given in chapter 7.9.2? > An occurrence definition or usage (that is not of a more specialized kind) can > be declared as described in 7.6.2 and 7.6.3 , using the kind keyword > occurrence. An occurrence usage may only be defined by occurrence definitions > (of any kind) or KerML classes (see [KerML, 7.4.3]). Syside implements validation rules from chapter 8 instead of trying to parse the intent of chapter 7. > [@Richard\_Wallace](#): > > I’ve read in the forum that 0.11.x is coming. I’ll upgrade and try again when Syside 0.11.x is available. There is nothing related to this in 0.11. ---
**Author:** ![Daumantas](https://yyz2.discourse-cdn.com/flex008/user_avatar/forum.sensmetry.com/daumantas/32/19_2.png) [@Daumantas](https://forum.sensmetry.com/u/Daumantas)\ **Post date:** [September 18, 2026, 7:36am UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/5 "2026-09-18T07:36:42Z")
Quickly went through the specification and found a bunch more similar semantic constraints only mentioned in passing in chapter 7 but entirely omitted from chapter 8: - `attributes` must be defined by `datatypes`. - `enums` must be typed by a single `enum def` when declared outside of `enum def`. - `occurrences` must be defined by `classes`. - `connections` must be defined by `assoc structs`. - `actions` must be defined by `behaviors`. - `behaviors` and `steps` should not have `result` if `return` is bound. - `requirements` must be defined by a single `requirement def`. - `cases` must be defined by a single `case def`. - `analysis cases` must be defined by a single `analysis case def`. - `verifications` must be defined by a single `verification def`. - `use cases` must be defined by a single `use case def`. - `views` must be defined by a single `view def`. - `viewpoints` must be defined by a single `viewpoint def`. - `renderings` must be defined by a single `rendering def`. ---
**Author:** ![Richard\_Wallace](https://yyz2.discourse-cdn.com/flex008/user_avatar/forum.sensmetry.com/richard_wallace/32/307_2.png) [@Richard\_Wallace](https://forum.sensmetry.com/u/Richard_Wallace)\ **Post date:** [September 18, 2026, 4:54pm UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/6 "2026-09-18T16:54:10Z")
Hi @Daumantas! Thanks for pointing out the semantic “misses” in the OMG specification between clauses (i.e., chapters) 7 and 8! While the definition syntax is usually understood, the meta-model static semantics seem to be missing. Syside either doesn’t enforce a lot of these semantics yet or only performs a first-pass, syntax-only semantics check (i.e., parser-phase checking). Regardless, if the OMG Pilot editor can catch the semantic issues, I’d hope that Syside would as well. What should my expectations be? Right now, I have to run all my code through Syside _and_ the OMG Pilot to make sure I’ve caught as much as I can. I’m not Ed S. 🙂, so my code can be janky at times. Has Sensmetry created a regression suite for semantic checking? I would expect that, but some of the missed semantic catches make me wonder 🧐 V/r, @Richard_Wallace ---
**Author:** ![Daumantas](https://yyz2.discourse-cdn.com/flex008/user_avatar/forum.sensmetry.com/daumantas/32/19_2.png) [@Daumantas](https://forum.sensmetry.com/u/Daumantas)\ **Post date:** [September 21, 2026, 6:40am UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/7 "2026-09-21T06:40:38Z")
> [@Richard\_Wallace](#): > > While the definition syntax is usually understood, the meta-model static semantics seem to be missing. Syside either doesn’t enforce a lot of these semantics yet or only performs a first-pass, syntax-only semantics check (i.e., parser-phase checking). Syside does perform both syntax and semantic checking. Nearly all validation rules defined in chapters 8 are implemented, see also [Validation Rules — Syside](https://docs.sensmetry.com/about/rules/). Currently only missing inherited name distinguishability across inheritance branches, and control node successions. Some structural constraints are enforced automatically by the model structure, some are inserted during semantic pass, e.g. implicit specializations. > [@Richard\_Wallace](#): > > Sensmetry created a regression suite for semantic checking? Yes, every new feature always comes with corresponding tests. We can only test what we know. * * * Will add the missing checks for the release after 0.11. ---
**Author:** ![Daumantas](https://yyz2.discourse-cdn.com/flex008/user_avatar/forum.sensmetry.com/daumantas/32/19_2.png) [@Daumantas](https://forum.sensmetry.com/u/Daumantas)\ **Post date:** [September 21, 2026, 10:50am UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/8 "2026-09-21T10:50:54Z")
> [@Daumantas](#): > > - `connections` must be defined by `assoc structs`. Seems like this is triggered by the standard library, and probably meant `associations` (not `assoc structs`). E.g. `Flows::Message` contains `connections` with `HappensDuring` types, which is an association, not an association structure. ---
**Author:** ![gwagner](https://avatars.discourse-cdn.com/v4/letter/g/41988e/32.png) [@gwagner](https://forum.sensmetry.com/u/gwagner)\ **Post date:** [September 24, 2026, 1:53pm UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/9 "2026-09-24T13:53:37Z")
@Daumantas Notice that in SysML2, connections between parts are both links and parts, so connection usages must be typed/defined by association structures, while KerML connectors, which subsume succession usages, are typed by associations. ---
**Author:** ![gwagner](https://avatars.discourse-cdn.com/v4/letter/g/41988e/32.png) [@gwagner](https://forum.sensmetry.com/u/gwagner)\ **Post date:** [September 24, 2026, 2:02pm UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/10 "2026-09-24T14:02:37Z")
> [@Richard\_Wallace](#): > > Thanks for pointing out the semantic “misses” in the OMG specification between clauses (i.e., chapters) 7 and 8! @Daumantas You should create a spec issue about this finding. ---
**Author:** ![Daumantas](https://yyz2.discourse-cdn.com/flex008/user_avatar/forum.sensmetry.com/daumantas/32/19_2.png) [@Daumantas](https://forum.sensmetry.com/u/Daumantas)\ **Post date:** [September 24, 2026, 2:08pm UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/11 "2026-09-24T14:08:22Z")
> [@gwagner](#): > > @Daumantas Notice that in SysML2, connections between parts are both links and parts, so connection usages must be typed/defined by association structures, while KerML connectors, which subsume succession usages, are typed by associations. Yes, `Flows::Message` contains SysML connections which are typed by an association, not an association structure. ![image](https://canada1.discourse-cdn.com/flex008/uploads/syside/original/1X/ad0f1a7794a63d3c484aac6bbbcb9ca4c3306230.jpeg) ---
**Author:** ![gwagner](https://avatars.discourse-cdn.com/v4/letter/g/41988e/32.png) [@gwagner](https://forum.sensmetry.com/u/gwagner)\ **Post date:** [September 24, 2026, 3:15pm UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/12 "2026-09-24T15:15:01Z")
> [@Daumantas](#): > > `Flows::Message` contains SysML connections which are typed by an association, not an association structure But these connection usages also subset binaryConnections, which is typed by an association structure, so they are typed by an association structure. It’s a fundamental conceptual choice of SysML2: connections are both links and parts. Consequently, connection usages are typed by an association structure, not just by an association! See also Fig. 19 in 8.3.13. ---
**Author:** ![Daumantas](https://yyz2.discourse-cdn.com/flex008/user_avatar/forum.sensmetry.com/daumantas/32/19_2.png) [@Daumantas](https://forum.sensmetry.com/u/Daumantas)\ **Post date:** [September 25, 2026, 6:08am UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/13 "2026-09-25T06:08:11Z")
> [@gwagner](#): > > But these connection usages also subset binaryConnections, which is typed by an association structure, so they are typed by an association structure. > > It’s a fundamental conceptual choice of SysML2: connections are both links and parts. Consequently, connection usages are typed by an association structure, not just by an association! > > See also Fig. 19 in 8.3.13. > A connection usage must only be defined by connection definitions (of any kind) or KerML association structures (see [KerML, 7.4.5]). Seems quite clear to me that `connections` may **only** have types that are `connections def` or `assoc structs`, and not `assocs`. Of course, this is the only sentence we have to go on since such constraints are not formalized in chapter 8. The implicit subsetting to `binaryConnections` does not override the `HappensDuring` with a more derived type so those connections, in addition to being defined by all the types of `binaryConnections`, also have a `HappensDuring` type which is neither `connection def` nor `assoc struct`. The types of `binaryConnections` are not the ones that violate the constraint as it is written, only the feature typing to `HappensDuring`. ---
**Author:** ![gwagner](https://avatars.discourse-cdn.com/v4/letter/g/41988e/32.png) [@gwagner](https://forum.sensmetry.com/u/gwagner)\ **Post date:** [September 25, 2026, 11:14am UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/14 "2026-09-25T11:14:45Z")
> [@Daumantas](#): > > Seems quite clear to me that `connections` may **only** have types that are `connections def` or `assoc structs`, and not `assocs`. Of course, this is the only sentence we have to go on since such constraints are not formalized in chapter 8. No, this is also stated in 8.3.13. > [@Daumantas](#): > > The implicit subsetting to `binaryConnections` does not override the `HappensDuring` with a more derived type so those connections, in addition to being defined by all the types of `binaryConnections`, also have a `HappensDuring` type which is neither `connection def` nor `assoc struct`. The types of `binaryConnections` are not the ones that violate the constraint as it is written, only the feature typing to `HappensDuring`. There is no violation. The subsetting to `binaryConnection` just implies another typing (by AssociationStructure), in addition to `HappensDuring`. And when a feature/usage is typed by several classifiers (such as `HappensDuring` and AssociationStructure), then its range is their intersection, which is a subclassifier of AssociationStructure, so any values of these connection usages are link objects.. ---
**Author:** ![Daumantas](https://yyz2.discourse-cdn.com/flex008/user_avatar/forum.sensmetry.com/daumantas/32/19_2.png) [@Daumantas](https://forum.sensmetry.com/u/Daumantas)\ **Post date:** [September 25, 2026, 11:50am UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/15 "2026-09-25T11:50:57Z")
> [@gwagner](#): > > No, this is also stated in 8.3.13. Does not seem like a statement of constraint like in chapter 7: > **8.3.13.4 ConnectionUsage** > > **Description** > > A `ConnectionUsage` is a `ConnectorAsUsage` that is also a `PartUsage`. Nominally, if > its type is a `ConnectionDefinition`, then a `ConnectionUsage` is a `Usage` of that > `ConnectionDefinition`, representing a connection between parts of a system. However, > other kinds of kernel `AssociationStructures` are also allowed, to permit use of > `AssociationStructures` from the Kernel Model Libraries. compared to > A connection usage must only be defined by connection definitions (of any kind) or KerML association structures (see [KerML, 7.4.5]). > [@gwagner](#): > > There is no violation. The subsetting to `binaryConnection` just implies another typing (by AssociationStructure), in addition to `HappensDuring`. And when a feature/usage is typed by several classifiers (such as `HappensDuring` and AssociationStructure), then its range is their intersection, which is a subclassifier of AssociationStructure, so any values of these connection usages are link objects.. Specification states that it is a _union_ > deriveFeatureType > > The `types` of a `Feature` are the union of the `types` of its `typings` and the `types` of the > `Features` it subsets, with all redundant supertypes removed. If the `Feature` has > `chainingFeatures`, then the union also includes the types of the last `chainingFeature`. > > ```ocl > type = > let types : OrderedSet(Types) = OrderedSet{self}-> > -- Note: The closure operation automatically handles circular relationships. > closure(typingFeatures()).typing.type->asOrderedSet() in > types->reject(t1 | types->exist(t2 | t2 <> t1 and t2.specializes(t1))) > > ``` Note that is no `deriveUsageDefinition` so I can only assume it is the same as `Feature::type` given that `definition` is a redefinition of `type`. And intersection should result in the less derived of the two, i.e. `Association ∩ AssociationStructure == Association`. ---
**Author:** ![gwagner](https://avatars.discourse-cdn.com/v4/letter/g/41988e/32.png) [@gwagner](https://forum.sensmetry.com/u/gwagner)\ **Post date:** [September 25, 2026, 12:25pm UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/16 "2026-09-25T12:25:17Z")
> [@Daumantas](#): > > Specification states that it is a _union_ You are confusing the (featured) types of a feature with its range (or co-domain): > A feature relates instances in the intersection of the extents of its featuring types (the domain) with > instances in the **intersection** of the extents of its featured types (the co-domain). [KerML 7.3.4.1] The values of a feature need to be instances of its range, which is more specific than its types. > [@Daumantas](#): > > And intersection should result in the less derived of the two, i.e. `Association ∩ AssociationStructure == Association` No, of course A ∩ (A ∩ S) = A ∩ S ! ---
**Author:** ![Daumantas](https://yyz2.discourse-cdn.com/flex008/user_avatar/forum.sensmetry.com/daumantas/32/19_2.png) [@Daumantas](https://forum.sensmetry.com/u/Daumantas)\ **Post date:** [September 25, 2026, 1:18pm UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/17 "2026-09-25T13:18:17Z")
Using `any` loses all practical cases for these constraints as semantic constraints already implicitly satisfy them. These validations are intended to catch users misusing definitions, so that e.g. `state` is not defined by `action def` even if it is implicitly defined by `state def`. Just slapping on a compatible definition should not suddenly make the constraint pass. Of the standard library and official examples, only these two connections violated any of the constraints _as they are written_ in the specification. This is also how it is implemented in the Pilot implementation: > Pilot implementation also checks for `Associations`, not `AssociationStructures` > ---
**Author:** ![Daumantas](https://yyz2.discourse-cdn.com/flex008/user_avatar/forum.sensmetry.com/daumantas/32/19_2.png) [@Daumantas](https://forum.sensmetry.com/u/Daumantas)\ **Post date:** [September 28, 2026, 6:52am UTC](https://forum.sensmetry.com/t/failure-to-flag-errors-from-syside-an-occurrence-item-or-part-must-be-typed-by-occurrence-definitions-duplicate-of-inherited-member-name-self/578/18 "2026-09-28T06:52:14Z")
I may have been unclear a bit. While `Feature::type` returns a union, it is only in the context of the resulting set of types. How that set is used determines whether it means a union or an intersection: - A union is checked as `any` — any type in set satisfying a predicate means that the set also satisfies the predicate. - An intersection is checked as `all` — all types in the set must satisfy a predicate for the set to also satisfy the predicate. Syside and Pilot implementation both use `all` consistently with specification.