Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

RASE Metamodel

RASE (Rapid Agentic Systems Engineering) is a Python-native MBSE (Model-Based Systems Engineering) metamodel for verifiable agent training. It implements SysML v2-like semantics using Pydantic models, without requiring external MBSE tooling.

Core Principle: RLVR (Reinforcement Learning with Verifiable Reward)

The reward signal comes from verifiable computation, not human feedback or learned approximations. The verifier is a first-class artifact — specified, reviewed, tested, and versioned alongside the agent it trains.

Oracle invariant: The oracle uses API ground truth (system state from NiFi REST API), never UI observations. UI traces (screenshots with Set-of-Mark annotations) are the training target — what the agent learns to produce. The oracle verifies whether the system reached the desired state, not whether the UI looked correct.

Four Coupled Models

RASE consists of four tightly coupled models. Changes to one often require updates to others:

ModelPurposePackage
SSMSystem State Model — system as typed graphgaius.rase.domains.nifi
OSMOperational Scenario Model — BDD scenariosgaius.rase.osm
UOMUI Observation Model — SoM/ToM groundinggaius.rase.uom
VMVerifier Model — requirements, oracle, rewardsgaius.rase.vm

The TraceableId spine links artifacts across all four models via URI-based identification (bdd://features/basic_flows#Scenario:CreateFlow, nifi://root/processors/abc123). The DigitalThread captures provenance relationships between artifacts.

Constraint System

Constraints are declarative, composable, and immutable (frozen=True). They evaluate against a SystemState and return structured ConstraintResult objects with rich failure messages:

# Atomic constraints
ProcessorExists(name="Generate Data")
ProcessorHasType(name="Generate Data", type_pattern="GenerateFlowFile")

# Composition via AllOf, AnyOf, Not
AllOf([
    ProcessorExists(name="Generate Data"),
    ProcessorHasType(name="Generate Data", type_pattern="GenerateFlowFile"),
    Not(ProcessorExists(name="Obsolete Processor")),
])

The constraint system is generic over SystemState via Constraint[S] — the NiFi domain provides NiFiInstance as the concrete state type, but the composition operators (AllOf, AnyOf, Not) work with any domain registered in the DomainRegistry.

Reward Computation

Verification produces a VerdictKind (PASS, FAIL, INCONCLUSIVE, ERROR) and an accuracy score (0.0–1.0): the fraction of constraints satisfied, computed as |{c in C : pass(c)}| / |C| with uniform weighting. Two reward strategies translate this into RL training signals:

StrategySignalUse Case
BinaryReward0.0 or 1.0Sparse signal — all-or-nothing. Suitable when partial credit is meaningless
GradedRewardContinuous, with configurable pass_reward and fail_penaltyDense signal with partial credit based on accuracy. Suitable for multi-constraint scenarios where incremental progress matters

The compute_reward() function is the single entry point: it takes a VerificationResult and a reward strategy, returning a scalar suitable for policy gradient updates.

SysML v2 Alignment

SysML v2 ConceptRASE Implementation
requirement defRequirement, ScenarioRequirement
verification defVerificationCase, APIVerificationCase
constraint defConstraint subclasses (composable via AllOf, AnyOf, Not)
action defStepDef with @given, @when, @then
part defProcessor, ProcessorGroup, NiFiInstance
Human ID <'scheme:path'>TraceableId.uri

Package Structure

src/gaius/rase/
├── core/                 # Domain-agnostic: SystemState, Constraint[S], Oracle[S]
├── domains/              # Domain-specific implementations
│   ├── base.py           # DomainSpec, DomainRegistry
│   └── nifi/             # NiFi domain (state, constraints, oracle)
├── traceability.py       # TraceableId, DigitalThread
├── osm/                  # Operational Scenario Model (BDD)
├── uom/                  # UI Observation Model (SoM/ToM)
└── vm/                   # Verifier Model (requirements, oracle, rewards)

Verification Discipline

All constraints are immutable (frozen=True), return structured ConstraintResult objects, and support declarative composition. The oracle consults the system API for reward computation — not the UI observation trace. This separation ensures that UI-level errors in training data do not corrupt the reward signal.

See Verification for the full reward computation pipeline, and RASE Models for detailed model documentation.