Hi @daviddekoning, we’re getting somewhere here. I think the specified vs. computed object “dichotomy” boils down to validation. E.g., As a little clash detection script, do I have a valid wall or not to operate on?
IFC, as a standard, has validation “built in”. Speckle doesn’t, and our stance is to let validation happen in the business logic, or as a separate layer (think of a quick automatic validation step). There’s several ways that I see you could implement this in the business logic:
- Based on commit source application: you can selectively run the clash detection script if data’s coming from Revit or an IFC file.
- Simply, based on object properties. E.g.,
if (!wall.whatever) throw new Error( 'Descriptive error message' ). This can easily replace the[Computed]attribute - you can also decide to compute that value on the spot if you can!
I’m usually wary of relying on .NET specific features like attributes for things too close to the core, as they don’t translate well in other languages. @teocomi’s [SchemaTag] proposal sounds good though, as it will allow us to control the behaviour of the component in Grasshopper and reduce complexity for the user. I’d see that as guiding the initial behaviour on instantiation, and I’d also allow, via right click, to swap between the two different behaviours (I’m sure some Gh hackers will want this sooner or later).
For example, structural elements will be defaulting to outputting the real elements, and our revit walls will remain the same; and if truly a grasshopper hacker, you can dig in the docs more and you’ll learn how to control the behaviour too 
I’ve raised an issue here, flagged it as p1 for next sprint!