docs: add DR-009-Infra on harmonizing dependable_element with sphinx/…

[antonkri]

Add a proposed decision record describing how the dependable_element concept is interlocked with the existing sphinx/sphinx-needs based S-CORE process: sphinx/sphinx-needs stays the single source of truth, requirements/AoU are exported via TRLC (with a TRLC metamodel check) into dependable_element, and architecture PlantUML files are shared between both worlds. Includes overview and merge diagrams.

[github-actions]

The created documentation from the pull request is available at: docu-html

[AlexanderLanin]

Thanks a lot for the write-up. I have tried that myself and invested 40+ hours into it. With no tangible outcome, as I was not able to collect benefits of TRLC/Lobster.

[AlexanderLanin]

I assume this DR is about introducing dependable_element and about how to integrate it into S-CORE docs-as-code. Not just about harmonizaton.

[antonkri]

In my opinion, the sphinx/sphinx-needs toolchain and dependable_element can be used together, with each having a slightly different focus. sphinx(-needs) focuses on requirements, architecture definition, and traceability more from a documentation perspective. dependable_element, on the other hand, focuses more on providing developer support to ensure, in a qualified manner, that all artifacts — including the traceability report — are valid and still reflect reality. This essentially covers what is currently handled manually through inspections and verification reports.

Some commercial solutions use a similar approach: on one hand, sphinx/sphinx-needs for the visualization of process artifacts, where validity checks are still needed to ensure that the rendered artifacts conform to the process metamodel. On the other hand, lean and easy-to-qualify solutions that produce, in a qualified manner, a traceability report — including additional checks to ensure that the artifacts and the traceability report still correspond to the reality in the source code.

[AlexanderLanin]

Contradiction: all detail design requirements are fully supported in S-CORE docs-as-code. Note however that there is almost no formal detail design documentation required by S-CORE process.

[antonkri]

Indeed, there are currently not many requirements for detailed design in the s-core process documentation (and this is not fault of docs-as-code tooling). However, I would consider this a pitfall rather than a good design decision. dependable_element already provides a definition of a unit (which is completely missing in s-core) as well as a number of checks — for example, verifying that unit APIs correspond to the architecture diagram — that we could simply reuse.

[AlexanderLanin]

Note that we typically don't expect many detailed design diagrams. See S-CORE process documentation.

[antonkri]

I guess, this is already covered by my comment above. I would consider this as a pitfall rather than a good design decision.

[AlexanderLanin]

"accurate dependencies" are provided by S-CORE docs-as-code. That's normal traceability, isn't it?!

[antonkri]

docs-as-code relies on sphinx. sphinx is not aware of our build system. It has its own workspace and this comes with some disadvantages, as you have to copy or mirror the whole data into sphinx workspace:

• sphinx doesn't always know what has changed, if you want to be sure you are using newest data, you have to do a clean build. This takes time. This may be ok for automated CI workflows, but not for normal developer experience
• sphinx doesn't know how you build your software, with which compiler flags, linker flags and so on. So there is no 100% guarantee you sphinx build is taking the same config, that is e.g. used for the final target build.
• It can be difficult in the future to address variants. E.g. your modules can have different variants (= feature flags), that you can activate or deactivate. Then you will need to be very careful what are you copying or what you are not copying. "Just copying" some data from bazel output folder doesn't work. Bazel knows what belongs together, you not.

I do not say it doesn't work with sphinx(-needs), you can get this working. But I am not sure, that this is the right tool for this task.

[AlexanderLanin]

full traceability is provided by S-CORE docs-as-code. See HowTo: Reference Docs in Tests

[antonkri]

I guess, I've addressed this already in my previous comments

[AlexanderLanin]

To my knowledge we had this discussion already, and clarified that it is and it can be used in safety-critical context. This paragraph needs a little more clarity with correct wording by safety experts.

[PandaeDo]

I would agree an this statement because of https://safety.useblocks.com/index.html. But we can always discuss potential concern in the process community meetings.

[antonkri]

To my understanding, as written here https://safety.useblocks.com/usage/qualification.html#qualification-method, a second lean implementation is used to verify the output of sphinx/sphinx-needs. I would say, the proposed solution in this DR goes exactly in the same direction with the only difference, that we do not use needs.json but lobster.json for traceability documentation.

I guess, the problem is not to qualify all the tooling around sphinx-needs and metamodel.yaml we've built in score. That should work well. The problem is that needs.json, that we check, is produced by sphinx - a huge large framework with a lot of additional packages and config options you can use. To qualify sphinx can be very challenging.

If you guys know someone, who has done qualification of sphinx without building additional tooling to parse sphinx-needs in rst files separately from sphinx, be my guest.

[AlexanderLanin]

Current relationships are also "first-class, machine-checkable edges". Please clarify the difference and why it is an improvement.

[antonkri]

explained here: #3097 (comment)

You do copy/link things from bazel build folder to sphinx workspace "manually", at least for verification report. I would not call it "first-class, machine-checkable edges".

[AlexanderLanin]

Current checks also run "deterministic and hermetic". Please clarify the difference and why it is an improvement.

[antonkri]

To my understanding, sphinx has its own logic for resolution of links and dependencies. So we have like one "build-system" running in context of another. I am not sure it is deterministic and hermetic.

[AlexanderLanin]

Same as S-CORE docs-as-code, so this doesn't sound like a difference. Please clarify how this differs.

[antonkri]

In case of docs-as-code, we have one central needs.json, as a result, the checks can be done only on this one needs.json. It means if you changes smth. in detailed design diagram and wants to know, whether this is still compliant with the implementation, then you will need to generate the whole needs.json and for this you will to build all the targets, e.g. verification report and for this to execute test and so on and so on.

In case of lobster, every bazel macro produces valid lobster.json reports, that can be used for validation. It means, to check that your detailed design is still valid, you will need to build only the lobster.json for detailed design. Only later, in the dependable_element, all lobster files are merged together in one for the final traceability check. That's the difference.

[AlexanderLanin]

Same as S-CORE docs-as-code, so this doesn't sound like a difference. Please clarify how this differs.

[antonkri]

yes, here at the end we get a complete lobster.json file, that is comparable with need.json. For the difference, please see the comment before.

[MaximilianSoerenPollak]

In my opinion this makes no sense to even start defining.

Older meeting minutes here: eclipse-score/communication#545 (comment)
We have had a meeting a while back where we decided we should get together and determine what even is the issue with this, what information exactly is needed for TRLC to work and how we can best provide it.

This meeting has not yet happened even after numerus attempts.
So in my mind the issue has lost importance and does not need to be addressed as the parties involved do not come together for a meeting.

I can not work on something that I do not know the requirements of, simple as that.

[PandaeDo]

Thank you for your perspective. But I would not agree from my experiences to your concerns against the actual solution, especially regarding qualification.

[PandaeDo]

I'm not a lawyer. But I guess we need to check if there is no licence conflict.

[antonkri]

yes, we should.

[PandaeDo]

Would not confirm this statement from the experiences we gained.

[antonkri]

can you please be more concrete?

[MaximilianSoerenPollak]

Needs.json is only an output that can be dependency as an input to other docuementation builds.
The check that it is conform is done inside the sphinx-build and the needs.json might be part of that if it comes from an external source, but the internal local one does not play a role.

[antonkri]

I agree and I don't see this as controversial to what I've written.

[MaximilianSoerenPollak]

So we then have to upkeep and keep in sync and verify two different metamodels?

[antonkri]

yes, true, that would be the consequence

[RolandJentschETAS]

Sounds like overengineering. I do not understand the benefit for introduction such a complex solution.

[MaximilianSoerenPollak]

What exactly is the difference here, compared to current implementation?
Why does the current implementation not work / provide what is needed?

[antonkri]

I guess, I've explained this in my previous comments:

• docs: add DR-009-Infra on harmonizing dependable_element with sphinx/… #3097 (comment)
• docs: add DR-009-Infra on harmonizing dependable_element with sphinx/… #3097 (comment)
• docs: add DR-009-Infra on harmonizing dependable_element with sphinx/… #3097 (comment)

[MaximilianSoerenPollak]

What about python and rust code, there this is not doable and therefore an issue?
Why is this a gap in the current implementation, was this ever a requirement to counter check the actual implementation against the needs you have defined?
IMO that should be part of the review process.

[antonkri]

• Yes, we will need to extend it for Rust.
• Review process is a manual step, it is better, if you have this automated.

[a-zw]

Suggested change

	source code ↔ tests. It treats everything as one big folder, where every
	change forces everything to be regenerated
	source code ↔ tests.
	- It treats everything as one big folder, where every
	change forces everything to be regenerated

This seems to be two arguments mashed into one bullet point.

[antonkri]

yes, will need to fix it, if the decision will be taken to merge this PR

[a-zw]

We don't need to qualify sphinx or sphinx-needs. We need to qualify score_docs_as_code (which internally uses sphinx and sphinx-needs).

[antonkri]

see #3097 (comment)

[a-zw]

I see two options to consider:

• integrate TLRC and LOBSTER
• extend score_docs_as_code

[antonkri]

I've kept this empty intentionally, I just wanted to have the discussion first.

[AlexanderLanin]

We cant really have a DR without options?

[a-zw]

The two options seem pretty obvious to me:

1. use TLRC
2. do not use TLRC and implement whatever is missing with Sphinx-Needs

Most of the description above should be moved into the TLRC option here.

[antonkri]

I introduce two options, but mainly I've provided the description of the goals for this DR in this commit: c1b488f

I hope, it makes it clearer.

[a-zw]

My understanding after the Infra meeting what this proposal aims for:

Suggested change

	- easy tool qualification
	- enable unit design and traceability around it
	- provide traceability report

[antonkri]

agree

[a-zw]

As a note: build speed should be an evaluation criterium

[antonkri]

agree

[antonkri]

In my opinion this makes no sense to even start defining.

Older meeting minutes here: eclipse-score/communication#545 (comment) We have had a meeting a while back where we decided we should get together and determine what even is the issue with this, what information exactly is needed for TRLC to work and how we can best provide it.

This meeting has not yet happened even after numerus attempts. So in my mind the issue has lost importance and does not need to be addressed as the parties involved do not come together for a meeting.

I can not work on something that I do not know the requirements of, simple as that.

Agree, that's really a pity, that the meeting has not happened. This DR is an attempt to refresh the discussion.

[a-zw]

Suggested change

	```mermaid
	```{mermaid}

This should fix the Sphinx build.

[antonkri]

Thanks, fixed it

[a-zw]

Suggested change

	```mermaid
	```{mermaid}

This should fix the Sphinx build.

[antonkri]

Thanks, fixed it

[RolandJentschETAS]

"The build emits" maybe better "The documentation build emits"

[RolandJentschETAS]

Is this really a "macro" ??? Better a "bazel command" ?

[RolandJentschETAS]

It is not defined and linked here, what LOBSTER means and why this has any advantage against the current sphinx needs process.

[antonkri]

Lobster is a tool for traceability report: https://github.com/bmw-software-engineering/lobster

It is also explained here: https://github.com/eclipse-score/tooling/tree/main/bazel/rules/rules_score

[RolandJentschETAS]

Isn't the dependable element already specified in the process ?

[antonkri]

To my knowledge it is not defined in the process but the tooling was already introduced: https://github.com/eclipse-score/tooling/tree/main/bazel/rules/rules_score

[RolandJentschETAS]

This is done by checklists and is not required by the ISO for ASIL B. So we had removed sphinx needs for unit to avoid slow down of development by process overhead and the code first approach.

[antonkri]

Yes, but I guess we all agree, that an automation is better as checklists, especially in open source project, where liability for manually created checklists is 0.0

[RolandJentschETAS]

It is already qualified and used in safety critical context. What kind of qualification is missing ? Therefore we have a tool classification.

[antonkri]

Currently I can speak for only one commercial solution, that I am aware about, and this is the one from use-blocks. For me, use-blocks is the company, that has exhaustive experience and understanding of how sphinx/sphinx-needs works. Based on their documentation, that is available on web, they use different lightweight tooling to parse rst files and to compare final result with what sphinx/sphinx-needs produces. So you do not qualify sphinx, you qualify another tool and then use this tool to ensure, that the output of sphinx is correct. This approach is comparable to what we purpose with this DR.

[RolandJentschETAS]

What makes it better with introduction of "lobster", which is only a more complex third party extension ? Sounds for me like "to cast out devils by Beelzebub".

[antonkri]

...aaa @RolandJentschETAS , I would disagree. And I think that's basically the main source of misunderstanding here. It is not about tooling. I would agree that everything you can do with dependable_element can be done with Sphinx and vice versa. Therefore, also all those comparison tables do not make much sense. It is about how you develop your software. The Sphinx approach we currently have is going more in the classic direction of software development in automotive, how we have it right now, e.g., with CodeBeamer. There is a big monolithic tooling that is not connected to the real build system or code at all. You fill in requirements and architecture and then we have tons of checklists that we need to fill manually. And if you want requirements and architecture being connected with source code, then buy commercial extensions and some IDE. Welcome back to the 20th century.

The creators of Lobster and dependable_element believe that requirements/architecture definition, code implementation, and testing should go hand in hand. The assumption is that as few manual checks as possible should be done — ideally zero. All should be checked automatically. Scripts for automated checks can be reviewed/evaluated later by the commercial distributor and reused. Manual reviews are for the bin.

[RolandJentschETAS]

What means "deterministically" here ?

[RolandJentschETAS]

Sounds for me like an artificial meta-meta-model.

[antonkri]

Not a meta-meta-model, but implementation/support of the score metamodel in bazel, ensuring every module defined its components , requirements and architecture in the same manner using the same tooling.

[RolandJentschETAS]

Sounds like promotion and support for useblocks. So we add here an dependency to an external commercial company ?

[antonkri]

Oh no, not at all. That's only the attempt to show, that also commercial solutions are using comparable approach as proposed by this DR.

[RolandJentschETAS]

Thats marketing ...

[antonkri]

same as above, not marketing, use-blocks is used here as reference.

[antonkri]

Some images for clarification:

Current solution

Proposed solution

[ubmarco]

First of all: thank you for writing this DR and for the energy behind it. We took it seriously enough to go deep before commenting — over the past weeks we audited docs-as-code, the score_tooling/rules_score stack, several module repos, the process requirements, and TRLC/LOBSTER themselves. The more we read, the more we found to genuinely like: the dependable_element idea of typed, buildable artifact groups, the LOBSTER evidence format (small, stable, with real report tooling), and above all the core demand — validation and evidence generation as artifact-scoped, deterministic actions the build system can schedule, cache, and re-run. That demand is right.

So let us say this clearly up front: we do not object to the "small, composable tools driven by the build" direction — we want it too. And we are willing to change our own tooling to make it real: the sphinx-needs ecosystem (sphinx-needs, sphinx-codelinks, sphinx-test-reports, and the engine behind the ubCode IDE extension) should support a file-based working mode — explicit file-list inputs, per-artifact extraction with stable JSON outputs, a Sphinx-free merge/validate step, and Sphinx consuming precomputed results as a renderer. An honest admission belongs next to that: today quite some computation runs inside the Sphinx build — source-code scanning for markers, for example. That is convenient and it works, but in our view this kind of work belongs outside the documentation build. It was never an engine limitation either way (the engine has separable phases and even validation-only builders); it is tool wiring, and we intend to improve it. Every piece of that re-wiring is trivially Bazel-wrappable. And to be fair to the current stack in the other direction: incremental rebuilds are already fast (3–6 s in docs-as-code's own benchmarks) and the relationships are machine-checked today — the gap is shape (artifact-scoped actions, build-visible contracts), not capability.

With the agreement established, here are the three points we believe the DR should take up, plus one about people.

1. One metamodel, lossless data path — no second requirements language

The DR already states the right premise: sphinx-needs stays the single source of truth. If that is the premise, the compliance-relevant data should not pass through a conversion into a second requirements language. The current rst_to_trlc bridge whitelists a handful of fields and drops other options and links — fine for what it was built for, but a compliance-grade bridge would need near-full fidelity, and at that point it has re-implemented the sphinx-needs data model with a second metamodel to keep in sync and govern forever.

Whether LOBSTER remains the assessor-facing evidence format is the project's decision, not ours to make — one of the things to align with the infrastructure team. If it stays (and it is a good, stable interchange), there is a cheaper path that keeps everyone's investment: export needs fragments / needs.json directly to the LOBSTER interchange (lobster-req-trace et al.) — a needs fragment being nothing more than a per-file, machine-readable extraction of the needs data, an ordinary build-action output — and feed the existing lobster_report / lobster-ci-report Bazel rules. Same assessor-facing evidence, same Bazel gates, one metamodel, no re-parse. Versioned references map cleanly too: sphinx-needs conditional links (REQ_123[version == 1], since 8.0) carry per-link version pins that translate directly to LOBSTER's item@version tags. We are happy to build this exporter as the first proof — see the offers below.

2. Requirements are markup — keep authoring where markup lives

Requirements, specifications, FMEA and FTA content are not plain strings: they are rich text with tables, images, and embedded diagrams. That is what every DOORS/codebeamer export and supplier specification looks like, and it is how S-CORE modules author today — PlantUML embedded inside requirement pages, and the process's own detailed-design template being a prose+UML document. TRLC is deliberately plain-text (a legitimate design philosophy for its purpose), which is exactly why it should sit at the evidence layer where that minimalism is a virtue — not at the authoring layer, where the loss is structural. The resolution is not "sphinx-needs or the build-native stack"; it is: author and render in sphinx-needs, validate and produce evidence as small build-schedulable tools. Both camps get to be right about their layer.

3. Surface the build knowledge as a contract — the missing chapter

What the DR does not yet discuss is how the artifact-combination knowledge is surfaced to everything that is not Bazel. "Which .puml belongs to which sources, tests, and requirement pages" lives inside rule implementations during the analysis phase. Every realtime consumer — an IDE, an AI agent, a Sphinx directive — then has exactly two options: embed Bazel, or read an exported contract. The Bazel-aware mode on the TRLC VS Code extension's main branch (unreleased at the time of writing) is genuinely impressive work, and it also demonstrates what the embed option costs: the language server runs bazel query itself, by default against a dedicated output_base per workspace so it does not interfere with the developer's builds, with a default query timeout of 180 s to accommodate cold Bazel servers. Every other tool that needs the same knowledge would have to pay the same price again.

The alternative has precedents inside S-CORE already: docs-as-code's score_sync_toml emits ubproject.toml for IDE consumption — the build system exporting its knowledge for other tools. And sphinx-mounts (DR-008, an active stream in the infrastructure team) was invented for exactly this family of problems: its bundle concept splits documentation and traceability sources across the repository into groups, with a config concept that represents each bundle in the IDE — working in dependency groups is being built as we speak. We propose generalizing exactly these patterns into a small, neutral, build-emitted trace manifest (the compile_commands.json idea applied to traceability): one JSON file declaring, per building block, which docs, code, architecture, and test artifacts belong together and where their derived fragments land. Bazel emits it via an aspect; Sphinx directives, IDEs, checkers, and AI agents consume it — nobody embeds anybody. We would like to co-develop that schema with you rather than ship one at you.

4. Usability decides adoption

A traceability process is only as good as the number of people who actually author into it, and requirements engineering lives or dies with authoring UX: instant feedback, navigation, previews — not edit → build → read a console log. That is why the contracts above must treat realtime consumers as first-class citizens — any editor can implement them. Ours already exists: the ubCode IDE extension is free for OSS projects and speaks these formats today, and we are ready to extend it along S-CORE's artifact model (building-block views, evidence status, drift feedback in the editor) — hermetic evidence for the assessor, realtime feedback for the engineer, same data.

Four corrections to the current DR text

Offered in the spirit of making the DR's fact base as strong as its idea:

1. "Support for detailed design is completely missing." The process itself makes detailed-design documents and diagrams optional and locates unit and interface descriptions in the source code (implementation_process_reqs.rst — "detail design description files … are optional"; "each unit shall have a description in the source code") — the implementation carries the detailed design. What is genuinely open are the automation-tagged process checks (diagram↔code consistency, dependency trees, complexity) — and those are a property of the build system and the toolchain wired into it, not of the requirements notation: where such tools have been wired up (the rules_score world — a C++ diagram↔code validator, build-graph checks), the checks exist; for the docs-as-code majority, for Rust modules, and for complexity they do not — under either notation. The same wiring is possible for the sphinx-needs stack — which is why offer 3 below proposes standardizing the check's interface first. We would suggest phrasing this item as the build-integration feature request it is, rather than as a toolchain instability.
2. "Sphinx and sphinx-needs cannot be properly qualified." "Not designed with tool qualification in mind" is fair; "cannot" is not — and the DR's own citation shows why. The linked useblocks qualification documentation describes a methodology whose subject is the Sphinx/sphinx-needs toolchain: a feature classification of Sphinx + Sphinx-Needs, a Qualification Kit with test cases for both, and a redundant two-toolchain verification method — offered together with innotec GmbH, a TÜV Austria Group member specializing in tool qualification. Small deterministic tools are easier to qualify — we agree and design for exactly that — but complex toolchains are qualified routinely (compilers being the canonical example), and if TRLC ever grows full markup support it will face the very same questions. One question the DR could settle for any stack: is the qualification target the traceability statements, or the rendered report?
3. "Commercial solutions take the same route." Speaking as the vendor cited: this section does not describe our products accurately, and we would ask to drop or rework it. ubTrace is a multi-user analysis and collaboration platform downstream of the Sphinx build — its ingestion runs Sphinx, and it consumes the same sphinx-needs data model; nowhere in our product line is there a second requirements language in the loop. What our stack actually demonstrates is "one metamodel + exported data contracts + interchangeable engines" — which supports the fragments route, not the conversion route.
4. Developer experience. The concern is right and we share it — but "every change forces everything to be regenerated" no longer matches docs-as-code's own 3–6 s incremental benchmarks, and developer experience ultimately surfaces in the IDE: diagnostics as you type, navigation, previews. That cuts both ways — build-anchored checks answer at build time, not keystroke time — which is why the surfacing contract from section 3 above (the trace manifest) matters for both worlds.

Concrete offers

One ground rule for all of these: any activity from these offers gets synced with the S-CORE infrastructure team first — these are offers to work with the project, not around it.

1. needs2lobster proof-of-concept, demoable in weeks: needs.json/fragments → LOBSTER requirement items (lobster-req-trace), feeding the existing lobster_report/lobster-ci-report rules and joining the implementation/activity fragments your existing producers already emit: the evidence pipeline with no conversion detour. This demonstrates the option — whether LOBSTER is the long-term evidence format remains the project's decision. Deliberately requirements-only — code and test evidence stay with their own per-target producers, exactly the LOBSTER model — and the requirement tracing tiers (component → feature → stakeholder / assumed-system) are demonstrable purely among requirements, matching the requirement-level .lobster files rules_score produces today. The natural delivery shape drops straight into the existing docs-as-code toolchain — a small Sphinx-side builder/converter over the needs data, the same pattern as the current custom extensions, and the same pattern LOBSTER itself already ships (sphinx_lobster registers a lobster builder for inline roles; the needs-aware counterpart is the missing piece). Venue best chosen together; a module where RST authoring is the incumbent would make it a fair test, with the interop leg shown against communication's existing reports.
2. Material for the DR's empty Options / Evaluation sections: we have a verified landscape and gap analysis of both stacks and are happy to contribute it as decision-ready content (Option A: TRLC conversion as drafted; Option B: native fragments + LOBSTER export; Option C: status quo + targeted gap closure).
3. Architecture-vs-code consistency: standardize the interface, not just the tool. gd_req__impl_diagram_consistency is a process requirement tagged for automation. The rules_score world already implements it for C++ in its wired modules (validation_cli — genuinely good work); the docs-as-code majority and Rust modules have nothing yet, and today the check's semantics live inside one tool's implementation. What "architecture is consistent with the code" means deserves to be written down as a standard: the architecture-model interface, the mapping rules (component ↔ target/crate/module, diagram entity ↔ code symbol), and the verdict semantics. Rust modules will pose exactly the same mapping questions soon, so now is the right moment. We offer to co-author that interface standard with the validation_cli authors — so every implementation, present and future (including our own), checks the same thing, and profiles interoperate rather than compete.

And two asks: adopt the trace manifest as the neutral contract between build system, docs, IDE and AI — and give us a named counterpart to iterate the manifest schema with (and, as that idea matures, a small per-block interface — exported IDs, types, versions; the ijar/.rmeta pattern that would make cross-block validation cacheable), so this becomes a workstream instead of a thread.

Smaller points — flagging now, happy to iterate in follow-ups

• Variant handling: sphinx-needs varies single fields/blocks per build configuration in place (needs_variants, the if:: directive); TRLC record values are literals, so variants mean whole-record duplication or per-file select() swaps — worth a design note before variants become load-bearing.
• Field-aware checks: LOBSTER's three-kind interchange is deliberately minimal (a virtue for stability) — but checks like "an open item must not be satisfied by links into closed items" need field predicates; the sphinx-needs schema language expresses these declaratively, and the results still export to LOBSTER.
• Justifications: per-item OK/PARTIAL/MISSING/JUSTIFIED with justifications is one of LOBSTER's best ideas — let's make justifications easy to author from the requirements source so they actually get used.
• Policy as a reviewed artifact: generated lobster.conf files land under bazel-out; for assessments it would help if the tracing policy were a versioned, reviewable document (generation from a reviewed declarative source is fine).
• Test-evidence normalization: gtest RecordProperty XML exists in two flavors and pytest properties in another; a shared converter should normalize all of them once, for both stacks.
• Metamodel maintenance: the process model currently lives in several encodings (.rsl, report configs, model schemas, validator profiles); a single schema source that the others are generated from would cut the sync burden regardless of which stack wins.
• Licensing of build-path tools: worth a deliberate look, because it matters to companies reusing the stack — TRLC is GPL-3.0 and LOBSTER is AGPL-3.0, which is workable for build-time tools but deserves an explicit statement of the intended posture; the same clarity should then apply to any new tools this DR leads to, whichever side contributes them.

---

Thanks again for forcing this conversation — it is the right one to have. Both sides of this debate are right about different layers, and the DR can be the place where that stops being a debate and becomes an architecture. We are ready to put engineering behind it.