Design modular participant control with extensible dynamic IFC and governed control effects #1068

Objective

Design the portable RAES architecture for composing participant-control
mechanisms, including extensible dynamic information-flow control (IFC), and
for applying their governed effects at participant/world crossings.

This is a general experimental and organizational control concern. Security,
adversarial evaluation, and safety are important applications, but they are not
the sole definition of the boundary.

Boundary to establish

RAES owns the declared world and the portable relations among participants,
world observations and actions, controllers, interventions, crossings,
profiles, decisions, effects, evidence, and claims.

Protection from actors and mechanisms outside that declared world is owned by
the backend or participant provider. Out-of-world tampering is an invalid or
failed realization, not a participant/world occurrence that RAES must model as
an attack. A live external environment may still be part of the declared world
when it is explicitly admitted as such.

Required exploration

Mechanisms and composition

• Treat dynamic IFC as one established mechanism with reusable literature,
  implementations, label propagation, policy resolution, and enforcement
  precedents; do not rename it into a new RAES-only abstraction.
• Determine which machinery from SEM-230 and SEM-233 can support revisioned
  label domains and policies beyond confidentiality/integrity while preserving
  SEM-233's existing security meaning and historical records.
• Assess composition with other mechanisms, including capability restriction,
  action admission, runtime shielding, monitors, approval and trusted editing,
  resource controls, controller handoff, interruption, and shutdown.
• Define how multiple profiles and mechanisms are selected for one apparatus,
  how mandatory and advisory results compose, and how conflicts, absence,
  unsupported behavior, weakening, and failure are represented.

Governed control effects

Define how resolved mechanism state may request existing typed RAES effects,
including permit, deny, withhold, transform, mask, inject, delay, route, audit,
handoff, request review, interrupt, and shutdown. The final vocabulary may reuse
or extend existing crossing, intervention, inject, transformation, and control
contracts; it must not become an arbitrary callback or open effects map.

Triggered effects must preserve exact state-cut resolution, fresh identity,
authority, provenance, participant visibility, evidence, idempotency, bounded
recursion/loop behavior, and ordinary downstream admission. A dynamic-IFC label
or monitor result establishes a fact or advice; it does not execute hidden code
or silently widen authority.

Portable/runtime/backend split

Decide and document:

• portable profile and mechanism-composition semantics owned by RAES;
• closed contracts and conformance owned by RAES;
• mechanism-neutral orchestration and final effect commit owned by the RAES
  runtime;
• concrete mechanism selection, implementation, agent/world instrumentation,
  and realization owned independently by each backend;
• apparatus selection and evidence that pin exact mechanism, profile,
  configuration, implementation, and limitation identities; and
• discovery/documentation responsibilities outside the runtime repositories.

The architecture must allow two conformant backends to choose different
mechanisms or implementations without implying semantic divergence or profile
parity.

Existing authority to reconcile

• Assess and design formal participant I/O control with information-flow and bisimulation semantics #794 and ADR-085 participant information-flow and control.
• Adopt adversarial AI-agent control and boundary-IFC threat models for participants #812, ADR-101, SEM-233, and ASR-536 adversarial participant flow control.
• Define adversarial participant boundary-flow semantics #1001 through Declare adversarial-control apparatus and backend capabilities #1004 semantic, contract, final-sink, and capability work.
• SEM-220/SEM-226 decision-surface and exposure semantics.
• API-409 control, API-423 crossings, RUN-310/RUN-319 runtime enforcement, and
  existing inject/intervention authorities.
• Experiment apparatus, profile, evidence, behavioral-claim, backend manifest,
  and conformance authorities.

ADR-101's non-goal for a general-purpose taint engine or policy language must be
explicitly preserved, amended, or superseded. This work must not silently
reinterpret an accepted decision.

Deliverables

• Current-state and literature-grounded architecture assessment.
• Accepted ADR or explicit amendments defining the responsibility split and
  composition model.
• Requirement disposition identifying reused, amended, and new Ground Control
  authorities.
• Mechanism/profile/effect vocabulary and composition rules precise enough for
  contracts and conformance.
• Worked non-security, adversarial, permissive-observation, strict-control,
  triggered-inject, and live-world cases.
• Complete dependency-ordered RAES, LilRAE, Shifter, evaluation, assurance, and
  documentation issue graph.

Acceptance criteria

• Dynamic IFC remains recognizable as IFC and is explicitly one of multiple
  participant-control mechanisms.
• An in-world adversarial input may be intentionally delivered and tracked
  rather than being classified as backend contamination or automatically
  blocked.
• Out-of-world integrity and containment remain backend-owned and outside RAES
  event semantics.
• Profiles can select more than one mechanism with deterministic, reviewable
  composition and no arbitrary execution ordering.
• IFC-resolved state can trigger governed injects and other typed effects, not
  only permit/deny or masking.
• Portable semantics, runtime orchestration, executable providers, backend
  declarations, backend realization, bounded conformance, and evaluation claims
  remain distinct statuses.
• Backend child issues do not require LilRAE and Shifter to choose the same
  mechanisms.
• Requirement authority exists before implementation children leave their
  blocked design state.

Non-goals

• Implementing a mechanism, plugin host, backend, or evaluation in this issue.
• Designing host, model-provider, credential, tenant, process, container, or
  network protection outside the declared RAES world.
• Creating an unrestricted plugin manager, callback language, generic metadata
  map, message bus, or universal gateway DTO.
• Making dynamic IFC the only permitted participant-control mechanism.
• Claiming universal noninterference, controllability, robustness, or backend
  equivalence.

Delivery graph

• Define extensible dynamic-IFC profiles and participant-control mechanism composition #1070 — dynamic-IFC profile and mechanism-composition semantics.
• Publish participant-control provider and profile contracts #1072 — participant-control provider and profile contracts.
• Evaluate applicable control providers in dependency order #1069 — runtime mechanism orchestration and triggered effects.
• Verify modular control obligations and realized effect outcomes #1071 — modular realization conformance.
• design: select LilRAE's initial participant-control mechanisms and profiles lilrae#1216, Implement and verify LilRAE's selected participant-control mechanisms lilrae#1224, and Verify selected control mechanisms across LilRAE world crossings lilrae#1225 — independent
  personal/local mechanism selection, realization, and proof.
• design(raes): define the participant-control mechanism and realization envelope Brad-Edwards/shifter#1967, feat(raes): realize selected participant-control mechanisms Brad-Edwards/shifter#1968, and
  test(raes): prove participant control across real participant/world crossings Brad-Edwards/shifter#1969 — independent Shifter mechanism selection,
  realization, and proof.
• Evaluate intentional subversion against realized control profiles #1007 — intentional-subversion evaluation consuming exact supported
  backend/profile evidence.
• Publish evaluation-backed adversarial control claims #1008 — bounded evidenced claims and nonclaims.
• OpenRAE/hub#36 and OpenRAE/hub#37 — cross-repository coordination and
  user-facing guidance.

Requirements

• SEM-235
• API-424
• RUN-320
• ASR-538
• ASR-536

These are OpenRAE/rae portable authorities. New SEM-235, API-424, RUN-320 and ASR-538 records and the ASR-536 amendment took authority through #1068 at merged revision ebb70a34b8e7d1cc8964c443841ae57e12ed1014; DRAFT does not mean implemented.

Design delivery

• ADR-108 and responsibility split, with an explicit ADR-101 scope amendment.
• Current-state and primary-source assessment.
• Composition revision 1, PC-01 through PC-15.
• Worked non-security, adversarial, permissive, strict, inject, conflict, restart and live-world cases.
• Requirement disposition.
• Complete dependency-ordered delivery graph and machine-readable graph.
• Bounded design verification and acceptance map.

The design and requirement authority was accepted at merged revision ebb70a34b8e7d1cc8964c443841ae57e12ed1014. This issue ships no mechanism, backend, runtime feature, conformance result or adversarial evaluation. The implementation children retain their prerequisite gates.

Delivery PR: OpenRAE/rae#1234, merged into dev as ebb70a34b8e7d1cc8964c443841ae57e12ed1014.