Skip to content

fix(processor): key decision-surface view classifications by compiled address - #1592

Draft
doublewhy wants to merge 9 commits into
devfrom
1572-view-relation-address-keys
Draft

fix(processor): key decision-surface view classifications by compiled address#1592
doublewhy wants to merge 9 commits into
devfrom
1572-view-relation-address-keys

Conversation

@doublewhy

@doublewhy doublewhy commented Oct 13, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Summary

Boundaries classify action contracts and tool-affordance bindings by authored reference, but decision-surface projection reads the compiled view relation by runtime address. So a boundary classifying only authored refs compiled, then failed projection: on dev cf8b4308 the new fixture's v1 projection reports "refs lack an effective view disposition at observation_order 0" and v2 "refs are not participant-visible".

The compiler now keys those two kinds by compiled address in view rules, transitions and timeline. Other refs pass through unchanged; only the section-qualified form resolves; a token naming two declarations fails as ambiguous. Authored refs stay on spec and *_refs.

This tightens compilation: two rules in one boundary that compile to one key now fail, naming both spellings (before, the later rule silently won). Migration (in docs/explain/sdl/sections.md): keep the authored rule with the other's disposition, drop the runtime-address rule, retarget its transitions. Literal-address-only boundaries (lilrae's techvault pattern) compile as before. No backward-compatibility claim.

Scope narrowed from the issue's Alternative 3 to these two kinds: keying every ref the alias index resolves (scratch edit, reverted) failed 18 existing tests, breaking bullet 3. Context refs belong to #300.

Stacked on #1576 (merged with dev cf8b4308), whose fixtures classify each binding twice, so bullet 2 lands on top of it. Both research captures are re-recorded on the combined source; outcomes unchanged.

Requirement UIDs

Related Issues

Closes #1572

Merge order: after #1446, #1584, #1576 and #1440 (shared schema-publication entries, #301 fixtures, docs/explain/sdl/sections.md); we rebase this the moment they merge.

Related, not changed here: #300, #1582, #1570, #1571, #219, #1341, #1362.

ADR Impact

  • No ADR required. Implements ADR-076 sections 3, 5 and 5.1 (exact canonical lookup, cardinality one, no dict insertion as collision detection, explicit migration), ADR-095 section 3, ADR-083 sections 5-6, ADR-022 section 4. No published schema changes (ADR-061).

Changes

  • compiler/view_relations.py: _information_keys, _information_key (ambiguity ValueError), _keyed_view_inputs (duplicate check before insertion), reusing _runtime_addressable_ref_index.
  • compiler/participant_contracts.py: _compile_observation_boundaries passes keyed inputs to the existing builders.
  • New fixture and 11-case test module; feat(sdl): add participant-scoped tool affordances for reusable tool profiles #1576's tool-profile fixtures, conflicts test and decision record migrated.
Done-when (verbatim) Change Fails without it CI lane Evidence
A regression test that compiles an SDL scenario classifying only authored references and projects v1 and v2 surfaces successfully. view_relations.py:_information_keys test_v1_projection_reads_authored_classifications_at_each_history_index, test_v2_projection_reads_authored_classifications (9 of 11 fail) canonical test-shard run 38385544070
The #301 fixtures can then drop their duplicated runtime-address rules. two-role-toolkit.sdl.yaml, shared-boundary.sdl.yaml #1576's modules (52 pass): 11 fail with compiler restored, 29 unmigrated canonical test-shard run 38385544070
Existing test_sem_220_* and behavior-history anchor tests unchanged. none modified 41 related modules: 1745 passed canonical test-shard run 38385544070

Test Plan

  • Unit tests pass
  • Integration tests pass if applicable
  • Completion command passes
  • No coverage regression

uv run --project implementations/python --frozen --all-extras python -m pytest implementations/python/tests/test_issue_1572_view_relation_address_keys.py -q gave 11 passed; with the two compiler files restored to #1576's version, 9 fail and the 2 pins pass. The 41 related modules gave 1745 passed. Evidence: captures recorded with python -m tools.research_capture record per docs/develop/research-captures.md (digest eb51137c649e); both evidence checkers pass. nox -s verify-fast-feedback -- --base-rev origin/dev passed on head c0556a76 (28 PASS, 1 SKIP), as did nox -s lint, make policy and nox -s docs-local. CI on c0556a76: run 38385544070 green; all checks pass (deploy skipped).

Ground Control Checks

  • Repository policy command passes
  • Pre-push code review and test-quality review completed, or not run for this lane

make policy passed.

Traceability

  • IMPLEMENTS: implementations/python/packages/raes_processor/compiler/view_relations.py, implementations/python/packages/raes_processor/compiler/participant_contracts.py
  • TESTS: implementations/python/tests/test_issue_1572_view_relation_address_keys.py, implementations/python/tests/fixtures/view-relation-keys/authored-classifications.sdl.yaml; migrated feat(sdl): add participant-scoped tool affordances for reusable tool profiles #1576 tests: implementations/python/tests/fixtures/tool-profiles/two-role-toolkit.sdl.yaml, implementations/python/tests/fixtures/tool-profiles/shared-boundary.sdl.yaml, implementations/python/tests/test_issue_301_participant_tool_profile_conflicts.py
  • Research captures only: docs/research/specification-coverage/captures/capture-4798f874.../, docs/research/formal-semantic-validation/captures/capture-d4e3fc83.../ and their capture-records receipts

Checklist

  • Code follows the project coding standards
  • FM2: validation and compiled visibility agree; differential tests against the SEM-220 model.
  • Published contract schemas regenerated if models changed: none changed.
  • PR title is a Conventional Commit
  • Architectural docs updated if applicable

Documentation

Updated: docs/explain/sdl/sections.md, docs/decisions/issue-301-participant-tool-profiles.md.

@doublewhy
feat(sdl): add participant-scoped tool affordances for reusable tool …
bff352d 
…profiles

A behavior specification's tool_affordances are its participant tool
profile. Each binding may now carry participant_refs and
participant_role_refs, which only narrow the specification's selection
and use the same PI-03 resolver over the composed scenario. Both empty
keeps today's meaning.

The validator rejects selectors that widen the specification, dangle or
name an authored __private ref, and checks each binding's actions and
boundaries against the participants it selects. Composition namespaces
explicit selectors and keeps roles global. The compiler records the raw
selectors and resolved participant addresses, with defense-in-depth
diagnostics, and makes the existing specification-level dangling
participant diagnostic reachable.

v2 projection offers a binding only to the participants it selects,
deciding scope from the raw selector lists so an empty resolution fails
closed. v1 refuses specifications with scoped bindings. Admission is
unchanged and independent of bindings.

The five SDL schemas and their publication records gain the two fields.
Docs, the ACT-619 formal section, the decision record and the migration
page describe the semantics, conflict classes and unsupported cases.

Refs #301
@doublewhy
chore(research): record branch captures for participant tool profiles
ef3fd74 
Specification-coverage capture capture-a2e0e332 and formal-validation
capture capture-f75b0d5e bind this branch's implementation digest
(bc5c3669) with zero formal replay drift. They follow
docs/develop/research-captures.md; outcomes, classifications and claim
limits are unchanged.

Refs #301
@doublewhy
test(sdl): split composite tool-profile assertions for Sonar
49f82d8 
SonarCloud python:S9073 flags two combined assertions and python:S5778
flags an exception test that builds its selection and admission request
inside pytest.raises. Assert each condition separately and build the
inputs first. Test-only; the research captures still bind the source.

Refs #301
@doublewhy
docs(sdl): state the absolute binding role-selector rule in the refer…
1195c8d 
…ence catalog

The tool_affordances participant_role_refs row said a role ref is fatal unless bound by a participant inside the owning behavior specification, which reads as the relative selector semantics the decision record rejects. State the absolute rule that TP-3 and the validator enforce: at least one participant has the role, and every participant with the role is inside the owning behavior specification. The parity expectation changes with the row.
@doublewhy
Merge dev cf8b430 into the stack on #1576 (1195c8d)
a34bf6c
@doublewhy
fix(processor): key decision-surface view classifications by compiled…
3f80c96 
… address

Observation boundaries classify action contracts and tool-affordance
bindings by authored reference (action_contracts.<name>,
behavior_specifications.<spec>.tool_affordances.<id>), but decision-surface
projection, history anchoring and exposure read the compiled view relation
by runtime address. A document that classified only authored references
validated and compiled, then failed v1 and v2 projection.

The compiler now keys those two declaration kinds in each boundary's view
rules, view transitions and view-relation timeline by their compiled
addresses. Every other information ref is carried as written, bare names
stay opaque, and a token that names more than one declaration fails
compilation as ambiguous. Two view rules in one boundary that compile to
one key also fail compilation instead of letting one disposition replace
the other. The raw authored refs stay on the boundary spec and its
observable, hidden and evidence ref lists.
@doublewhy
test: classify tool-profile bindings once by authored reference
1f28c75 
The issue #301 tool-profile fixtures classified each binding under both
its authored reference and its literal runtime address, because
decision-surface projection read only the runtime address. With view
classifications keyed by compiled address, the two rules share one key
and compilation rejects the boundary.

two-role-toolkit and shared-boundary now keep only the authored binding
rules (with the dispositions the literal rules had) and drop the literal
rules and their observable_refs and hidden_refs entries. The
disclose-passive-scanner transition targets the authored scanner-white
reference. The conflicts test adds its hidden audit-blue binding once,
by authored reference, and its unclassified-boundary case drops the
white binding's disclosure transition together with its rule.
Action-contract rules and the blue binding at white-view, which have no
authored twin, keep their runtime addresses.
@doublewhy
test: record research evidence captures for issue #1572
ecc33c5 
Specification-coverage capture capture-4798f874 and formal-validation
capture capture-d4e3fc83 bind the implementation digest of this branch,
which combines dev cf8b430, #1576 1195c8d and the issue #1572 change;
outcomes and claim limits are unchanged.
@doublewhy
doublewhy force-pushed the 1572-view-relation-address-keys branch from 666f684 to ecc33c5 Compare October 13, 2026 10:02
@doublewhy
docs(decisions): record #1572 as fixed in the #301 tool-profile record
c0556a7 
The #301 record listed #1572 under tracked gaps, saying the #301 fixtures classify each binding under both its authored reference and its runtime address. This branch fixes #1572 and migrates those fixtures to one classification per binding, so the bullet moves out of the tracked gaps and states the combined behavior.
@doublewhy
doublewhy marked this pull request as ready for review October 13, 2026 11:15
@doublewhy
doublewhy marked this pull request as draft October 13, 2026 18:36
This was referenced Oct 13, 2026
Merged
Merged
Open

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@doublewhy