[devin-ai-integration]

What and why

The subject parameter a satisfy requirement r : R by sys declares (an unnamed ReferenceUsage owned through a SubjectMembership, #1806) read natively with isVariable = false and owned no membership, while the RDF export states isVariable/mayTimeVary true for it (a referential usage of the satisfy usage, an Occurrence) and a FeatureValue binding it to sys — two measured cross-ledger disagreements in qvts (Cross_ReferenceUsage_isVariable and _ownedRelationship of Observatory__observatory___400_subject). The subject's declaration is the by Relationship node, which Usage::mayTimeVary, Feature::isVariable and the value-part reader did not recognise. They now do: the subject derives mayTimeVary (and so isVariable) from its owning satisfy usage like every other parameter — on both derivations, UsageMayTimeVary and UsageMayTimeVaryForOwningType — and its value part is the by target, so ValueExpression and OwnedMemberships yield the FeatureValue the conversion writes.

A chained subject (by sys.sub) is written as the pilot grammar spells it (SysML.xtext SatisfactionReferenceExpression): a FeatureReferenceExpression owning a chain Feature at referent (OwningMembership + one FeatureChaining per link), then its result — not the FeatureChainExpression a chained value elsewhere is. The reflective read mirrors that shape for a subject's chained value (metaclass, referent, owned memberships, chainings), and the id reader registers the value, chain Feature, chainings and result under the ids the writer mints, so the two ledgers agree element for element.

Specification basis

SysML v2 8.3.19 (SatisfyRequirementUsage, the by clause binds the subject parameter), 8.3.6.4 (Usage::mayTimeVary), KerML 8.3.3.3.5 (Feature::valuation subsets ownedMembership). No spec-compliance row moves.

How it was verified

• TestSatisfySubjectMembershipIsOwned extended: UsageMayTimeVary, FeatureIsVariable and the reflective isVariable read true; ValueExpression(subject) is the by value and the subject's one owned membership is the FeatureValue owning it (all fail before this change).
• New TestSatisfySubjectValueReadsAsTheConversionWritesIt (export parity): for by sys and by sys.sub, the native value's metaclass, owned-membership classes, referent, chaining features and the ids of the value, chain Feature and FeatureChainings equal the written graph's (fails without the reflective mirror).
• go build ./..., go vet, gofmt -l . empty; go test ./internal/semantic/... ./internal/doc/... ./internal/translate/export/... ./tests/export/... green. The writer is unchanged — only the id reader (recordSatisfySubjectValue) learns the ids the writer already mints — so the api-json baseline moves by its provenance digest alone.

Checklist

• make test and make lint pass locally
• Tests added or updated for the change
• Documentation extended where it already covers the surface (see CONTRIBUTING.md)
• Changelog entry added as changes/unreleased/<slug>.<section>.md, not as an edit to CHANGELOG.md
• baselines regenerated and make docs-counts run if a gate count moved (compliance rows need nothing: the census is counted at docs build)
• No internal work-item labels (waves, slices, F4, K5) in the body, docs, or changelog

Link to Devin session: https://nasa-jpl-demo.devinenterprise.com/sessions/18ad47adf36f44e9b6824a4472f9678d
Open in Devin Desktop: https://nasa-jpl-demo.devinenterprise.com/desktop/session/18ad47adf36f44e9b6824a4472f9678d?variant=devin
Requested by: @NicolasRouquette

---

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

• Disable automatic comment, CI, and merge conflict monitoring