# RTracer Universal Mobility & Utility Substrate v1.4

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Normative release: 1.4.0
> Presentation bundle: 1.4.1

# Front matter

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.front-matter · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:70624917e8fe55fc32769ff61dcf2320e47c95033622de911454c73171e86824

UNIVERSAL ONTOLOGY + EXTENSION SPECIFICATION

RTracer Universal Mobility & Utility Substrate

A generative classification, configuration, and lifecycle system for any vehicle, mobile machine, robot, model, assembly, or future hybrid.

Prepared for: RTracer team

Concept and direction: LNK

Companion to: RTracer Universal Vehicle Identity & Lifecycle System

Scope: Physics, control, identity, evidence, whole-life engineering, canonical ledger, telemetry runtime, governed agents, commerce, APIs, and conformance

Status: Implementation-standard edition v1.4 • 22 July 2026

```text
The substrate law
No finite list can contain every vehicle. RTracer therefore stores stable, orthogonal facts and derives named types as versioned recipes. A fan-propelled bicycle, an air-propeller boat, a submerged-propeller boat, a transforming drone-car, or a future machine can be described without adding a new core table or corrupting an old category.
```

The 471 seed recipes are intentionally broad; the generative model is intentionally broader than every finite catalog.

# How to read this specification

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.guide.how-to-read · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:d6ef4e0041d6d407e472b0f00b627e5c32bc6c4260a277aafe926bb5aad6f6a2

Sections 1–3 define the open-world architecture. Sections 4–16 cover movement, control, utility, parts, configuration, lifecycle, measurements, domains, packs, implementation and invariants. Sections 17–24 deepen semantics, identity, mechanism, control, lifecycle, telemetry, vehicle-native agents and governance. Sections 25–44 define exact records, ledgers, runtime, schemas, math, telemetry, physics, safety, identity, markets, APIs and operations. Sections 45–54 add executable institutions, casework, title, insurance/repair, moderation, youth protection, management teams, tax, incident response and market integrity. Section 55 and Appendices N–Q define the v1.4 corrective profiles, migration, immutable release bundle and agent contract.

| Part | Purpose |
| --- | --- |
| 1–3  Substrate | Admission, durable identity, facets, type recipes, vocabulary governance |
| 4  Movement physics | Support, energy, conversion, force, interface, steering, stopping and stability |
| 5  Control | Human, remote, assisted, scripted, autonomous and mixed authority per function |
| 6  Utility | What the machine can carry, sense, transform, manipulate, produce or serve |
| 7–10  Whole machine | Systems, parts, interfaces, configurations, modifications, service, tests and failures |
| 11–12  Domains + types | Medium transitions, operating envelopes and a wide canonical recipe catalog |
| 13–16  Governance | Standards adapters, schema mechanics, difficult examples, invariants and rollout |
| 17–20  Semantic depth | Knowledge states, identity continuity, coordinates, rare mechanisms and control transitions |
| 21–24  Implementation depth | Digital thread, telemetry evidence, agents/markets, security and executable contracts |
| 25–28  Canonical contracts | Wire primitives, claims/evidence, immutable configuration graphs and lifecycle transactions |
| 29–32  Runtime + APIs | Telemetry/media ingestion, ledger/replay/scale, governed action/market execution and conformance |
| 33–36  Wire + computation substrate | Exact canonical bytes, digests, proofs, SQL append, registry evolution, units, frames, clocks and test equivalence |
| 37–40  Runtime semantics | Telemetry protocol, physics/capability compiler, control leases/safety and grounded vehicle-agent runtime |
| 41–44  Governed production system | Identity/privacy, auctions/accounting, HTTP/events/SDKs, deployment, SLOs, replay and release engineering |
| Appendices | 84 official references, 50 edge recipes, 256 implementation fixtures, wire/state matrices and KUN plus cross-domain traces |

```text
Three precision rules
Support is not propulsion. Propulsion is not useful action. A regulatory label is not the physical type of the machine. Keeping those distinctions prevents almost every category failure in a universal vehicle system.
```

> v1.4 corrective release — record-core semantics remain stable while operational ordering, proof targets, confidential cursors, reboot-safe control, atomic external dispatch, executable institutions, migration, and release discovery become exact. See Section 55 and Appendices N–Q.

# 1. The open-world design goal

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.01 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:d87ac894db4fbb2e1c8333c95cc9d5cf788e5de7f1cc89c088f3d4c447a63b87

The vehicle universe is combinatorial. Wheels can support a body while a fan pushes against air. A hull can float while a propeller pushes water, a sail pushes against air, or a towline supplies force. One aircraft may roll, float, fly, hover, taxi and fold; one robot may drive, climb a wall and manipulate a valve. The schema must preserve each fact independently and let familiar names emerge from their combination.

```text
A vehicle type is a query result—not the storage model
‘Electric scooter’ can resolve to a type recipe that requires a stand-on or seated personal platform, rolling ground support, electric energy storage, motor torque, wheel-ground traction, and a compatible control arrangement. ‘Fan-propelled bike’ changes the force-generation path while preserving bicycle support and steering. The instance keeps its facts even if the preferred label changes.
```

### Six substrate principles

- Open world: an unknown class does not make the asset invalid; it can still be described by universal facets.

- Multi-class: one asset may simultaneously match several physical, operational, cultural, commercial, and regulatory recipes.

- Configuration-aware: classifications apply to an exact build and may change after a modification, payload swap, transformation, or coupling.

- Operation-aware: the same build may be crewed, remote, scripted, assisted, or autonomous in different functions and missions.

- Authority- and time-bound: every external class records who issued it, under which rule version, in which jurisdiction, and for what interval.

- Evidence-bearing: measurements and important assertions retain source, method, uncertainty, provenance, and correction lineage.

![Five-layer diagram: stable kernel, type recipes, domain packs, external classifications, and the exact instance and operation.](/substrate/v1.4.1/assets/media/image2.png)

The kernel stays stable; knowledge grows through versioned vocabularies, recipes, packs, and mappings.

### What ‘fully encompassed’ can honestly mean

It cannot mean that a static document predicts every future leaf name. It means the substrate can represent an unanticipated combination without migration, loss of meaning, or an ‘other’ bucket. The type catalog is a high-coverage seed library. The facet system is the completeness mechanism.

# 2. Universal identity and object boundaries

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.02 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:cbfc9601b76c925a98408adc22e434ba5b8005de2500a4288de55779c5d8efa2

Use EmbodiedAsset as the root for persistent physical engineered objects. VehicleAsset is an embodied asset whose intended capabilities include locomotion or conveyance. MobileMachine adds work performed while moving or between moves. A passive carrier, attachment, component, temporary assembly, persona, digital twin, and software agent remain related but distinct objects.

| Kernel object | Meaning | Boundary rule |
| --- | --- | --- |
| EmbodiedAsset | Durable physical engineered identity | Root of physical identity; never a person |
| VehicleAsset | Locomotion and/or conveyance is an intended capability | Self-propulsion is optional |
| MobileMachine | Moves and performs useful work | May also be a VehicleAsset |
| Conveyance | Carries people, animals, cargo, instruments or another asset | May be passive, ambient-powered or externally moved |
| Equipment / Attachment | Adds function when mounted, coupled or carried | Can be separately serialized without being independently mobile |
| ComponentInstance | Serial, lot or individually tracked constituent | Keeps its own install, service, meter and custody history |
| Assembly | Dated composition of assets and components | Formation does not erase member identities |
| ConfigurationSnapshot | Immutable exact realized build | Required context for operation, test, event and claim |
| Operation / Mission | Bounded use in time, place, purpose and envelope | Control and regulatory status attach here when appropriate |
| Persona | Public character, voice, canon and account | Can outlive or transfer separately from the physical asset only by policy |
| DigitalTwin | Computational representation and state projection | Never treated as the physical source of truth by default |
| Agent | Software actor with scoped mandates | No implicit ownership, legal personhood or physical authority |

### Admission and identity continuity

- Admit self-propelled, human-powered, animal-powered, ambient-powered, externally propelled, gravity-driven, launched, tethered, guided, carried and passive conveyances.

- Record models and replicas as real assets with explicit scale and represents relationships; never merge a 1:8 model with the full-size vehicle it depicts.

- A temporary consist—tractor plus trailer, train, tug plus barge, rocket stack, drone plus payload—receives an assembly identity for the interval.

- Rebuild, replacement shell, re-chassis, stage separation, split, merge, replica and recovered parts require explicit identity-continuity decisions with evidence.

- Human users remain principals with rights. Wheelchairs, exoskeletons and prosthetic machines may be assets; their users are not components or property.

# 3. The generative classification model

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.03 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:9cab1142c409e8e4a0bdf727f24e9cdd4b4c08251255790a4107a6c38de50b57

```text
Canonical assertion
ClassificationAssertion(subject, facet, value, classification_context, configuration_ref, operation_ref, effective_interval, jurisdiction, authority, vocabulary_version, evidence_ref, confidence, status).
```

Do not store a single vehicle_type field as truth. Store many sourced facet assertions. A TypeRecipe is a named, versioned set of required, optional, forbidden, and derived facet constraints. A DomainPack supplies vocabulary, forms, validators, event payloads, units, user experience and external mappings for a community. The same instance can match several recipes and packs.

| Classification context | Question answered | Example |
| --- | --- | --- |
| Physical | What is it and how does it work? | Wheeled, hydrostatic hull, electric motor, air propeller |
| Design | What family or architecture was intended? | Cargo bicycle, tiltrotor, catamaran, tracked excavator |
| Configuration | What is installed right now? | Road wheels fitted; float kit removed; firmware 4.2 |
| Operational | How is it being used in this mission? | Uncrewed survey, towed transfer, passenger service |
| Control | Who or what controls each function? | Remote steering; automated stabilization; human payload operator |
| Regulatory | How does an authority classify this operation? | EU L-category, EASA Specific operation, local vessel class |
| Competition | Which event/rule class accepts it? | 1/8 electric buggy; GT3; unlimited hydroplane |
| Commercial | How is it listed, valued, insured or financed? | Light commercial vehicle; recreational craft; collectible model |
| Social / cultural | How does its community understand it? | Rat rod, workhorse, sleeper, battlebot, iconic blimp |

### Universal facet groups

| Facet group | Representative axes |
| --- | --- |
| Identity + existence | asset kind; lifecycle state; physical/digital; prototype/production/replica/model; scale; continuity lineage |
| Geometry + structure | dimensions; mass; frames; body architecture; hull/airframe/chassis; articulation; modularity; deformability |
| Operating medium | solid surface; rail/guideway; ice/snow; water surface; submerged; air; near-space; space; subsurface |
| Support / lift | contact; suspension; hydrostatic/hydrodynamic buoyancy; aerodynamic lift; aerostatic lift; cushion; tether; field |
| Path constraint | free; road; lane; track; rail; cable; groove; pipe; wall; geofence; orbit; convoy; carrier-constrained |
| Energy + resources | source; carrier; store; feed; oxidizer; working mass; ambient capture; external force; consumables |
| Conversion + transmission | converter; power electronics; gearing; hydraulics; pneumatics; shafts; distributed drives; losses |
| Force + interface | torque/thrust/lift/pull/impulse; wheel/track/leg/sail/rotor/propeller/jet/nozzle/field; reaction medium |
| Guidance + stopping | steering; attitude; trim; braking; reverse; anchoring; mooring; station keeping; parking; holding |
| Control | function; actor; location; command form; link; authority; assistance; autonomy; handover; fallback; ODD |
| Perception + navigation | sensor modality; localization; mapping; state estimation; planning; traffic coordination; comms |
| Occupancy + payload | crew; passengers; animals; cargo; payload; accommodation; accessibility; containment; dangerous goods |
| Action + utility | carry; tow; lift; manipulate; process; sense; film; spray; dig; build; generate; race; rescue; serve |
| Coupling + formation | tow; hitch; dock; consist; swarm; leader/follower; carrier; refuel; stage; detachable payload; transform |
| Operating envelope | terrain; depth; altitude; orbit; weather; temperature; pressure; sea state; grade; clearance; legal area |
| Performance | speed; acceleration; range; endurance; capacity; drawbar pull; thrust; lift; efficiency; accuracy; duty cycle |
| Safety + recovery | hazards; containment; redundancy; fail-safe; emergency stop; escape; recovery; rescue; deorbit; disposal |
| Software + cyber | firmware; calibration; models; data buses; protocols; identity; credentials; updates; security zones |
| Lifecycle + condition | manufacture; service; care; wear; inspection; modification; damage; restoration; storage; end-of-life |
| Trust + rights + economy | ownership; custody; operation; evidence; privacy; licenses; market instruments; insurance; earnings |

### TypeRecipe semantics

- Recipe terms have stable identifiers, human labels, synonyms, definitions, version, owners, change notes and deprecation mappings.

- Constraints may be required, optional, one-of, at-least-one, forbidden, range-based, conditional or derived.

- Recipes can inherit from several parents, but stored facet assertions remain the source of truth.

- A match result reports exact, probable, partial, conflicting or indeterminate and explains which assertions caused the result.

- Community aliases do not overwrite technical vocabulary: ‘hoverboard,’ ‘roadster,’ and ‘drone’ can be disambiguated by context.

- External registry mappings are adapters with authority and effective dates; they never redefine the kernel.

# 4. Universal movement physics

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.04 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:34cd80c60038680b3e18aa9a6ddbdc7cf82c64078ac3cf6c687d20a4edf6b499

![Three parallel graphs: support and lift, propulsion, and useful action. Each graph has distinct inputs, mechanisms, interfaces, media, outputs and evidence.](/substrate/v1.4.1/assets/media/image3.png)

A vehicle may have several active paths in each graph and may switch paths during an operation.

```text
Required separation
Support explains how loads are carried. Propulsion explains how commanded force or impulse changes motion. Action explains what useful work is performed. A blimp’s helium supports it; electric propellers move it; a camera payload performs the mission.
```

### 4.1 Support, lift, and load-bearing mechanisms

| Support family | Realizations | Differentiating domain |
| --- | --- | --- |
| Rigid contact | Wheels, rollers, balls, casters, skids, skis, shoes, contact pads | Solid ground, deck, wall, ice, snow |
| Compliant contact | Tires, suspension, compliant feet, soft tracks, airless structures | Controls load distribution and terrain following |
| Continuous contact | Tracks, belts, screws/augers, rolling drums | Low ground pressure, loose media, climbing or crawling |
| Intermittent contact | Legs, hopping, running, brachiation, inchworm, snake-like segments | Discrete contacts and gait phases |
| Guided contact | Rail wheels, flanges, guide rollers, rack, slot, groove, pipeline contact | Infrastructure constrains path |
| Field support | Magnetic levitation, electromagnetic suspension/repulsion | Guideway and controlled fields carry load |
| Air cushion | Hovercraft skirt, surface-effect cushion, air bearing | Pressure cushion over land, water or prepared surface |
| Hydrostatic | Displacement hull, pontoon, submerged buoyancy, ballast system | Buoyant force from displaced fluid |
| Hydrodynamic | Planing hull, hydrofoil, lifting body, dynamic diving plane | Forward motion creates lift or support |
| Aerodynamic | Fixed wing, rotor, flapping wing, parafoil, kite, lifting body | Airflow creates lift |
| Aerostatic | Helium/hydrogen gas cell, hot-air envelope | Lighter-than-air buoyancy |
| Ballistic / orbital | Free flight, ballistic arc, orbit, free-fall | No continuous support interface in the usual sense |
| Tethered / suspended | Cable car, gondola, crane-suspended carrier, tethered balloon | Cable or structure carries some or all load |
| Externally carried | Vehicle on trailer, aircraft carrier, mothership, launch rail | Carrier bears load during a phase |
| Mixed / transitioning | Amphibian, seaplane, roadable aircraft, launch-and-recovery craft | Multiple methods with transition conditions |

### 4.2 Resource, energy, and feed taxonomy

| Resource family | Examples and modeling notes |
| --- | --- |
| Human / animal biochemical | Muscle input via pedals, oars, push, pull, walking or direct carriage |
| Stored electrical | Primary/rechargeable battery, supercapacitor, flywheel-generator combination |
| External electrical | Overhead wire, third rail, tether, conductive rail, inductive supply, charging while stationary |
| Electrochemical generation | Fuel cell supplied by hydrogen, methanol, ammonia or another reactant system |
| Liquid chemical | Gasoline, diesel, kerosene, alcohol, biofuel, nitromethane blend, monopropellant |
| Gaseous chemical | Hydrogen, methane/CNG/LNG, LPG, stored producer gas |
| Solid / hybrid chemical | Solid rocket propellant, hybrid fuel grain plus oxidizer, solid fuel combustion |
| Oxidizer | Atmospheric oxygen, liquid oxygen, nitrous oxide, peroxide or other stored oxidizer |
| Stored mechanical | Spring, elastic band, compressed gas, hydraulic accumulator, flywheel, raised mass |
| Solar / radiant | Photovoltaic electricity, solar thermal, solar sail radiation pressure |
| Wind / current / wave | Sail, kite, turbine, current drag, wave-energy conversion |
| Gravity / altitude | Downhill motion, gliding, pendular or counterweight system |
| Nuclear / radioisotope | Reactor-derived power, radioisotope heat/electricity |
| External mechanical | Tow, push, launch, catapult, winch, cable haul, carrier release |
| Ambient thermal / pressure | Thermal gradients, buoyancy changes, atmospheric or fluid pressure differentials |

### 4.3 Conversion, transmission, and force generation

| Stage | Controlled vocabulary seed |
| --- | --- |
| Converter | electric motor; combustion engine; steam engine; gas/steam turbine; fuel cell; hydraulic/pneumatic motor; muscle; sail/wing; thermal engine; reactor-generator |
| Power conditioning | inverter; ESC; rectifier; regulator; converter; clutch; torque converter; governor; valve; pump; compressor |
| Transmission | direct drive; shaft; chain; belt; gear train; differential; CVT; hydrostatic; hydraulic line; pneumatic line; electrical bus; distributed drive |
| Force generator | traction torque; propulsive thrust; aerodynamic lift; drawbar pull; cable tension; jet momentum; impulse; magnetic force; buoyancy modulation |
| Movement interface | wheel; track; leg/foot; ski/skid; rail wheel; screw/auger; propeller; fan; rotor; sail; oar/paddle; waterjet; nozzle; tether; field |
| Reaction medium | ground; rail; snow/ice; air; water; expelled working mass; cable/structure; magnetic guideway; radiation field; another vehicle |

### 4.4 Propulsor and locomotion families

| Family | Examples | Physical discriminator |
| --- | --- | --- |
| Rolling traction | Driven wheel, roller, sphere, drum | Torque reacts through solid contact |
| Continuous traction | Track, belt, screw/auger | Extended contact or loose-media reaction |
| Legged / body | Walk, run, hop, crawl, slither, inchworm, climb, brachiate, burrow | Gaits and contact sequence matter |
| Air propeller / open fan | Tractor/pusher propeller, open fan, ducted fan | Thrust reacts against air regardless of support medium |
| Marine propeller | Submerged, surface-piercing, contra-rotating, azimuthing | Thrust reacts against water |
| Pump / water jet | Impeller, waterjet, pump-jet | Water ingested and accelerated through duct/nozzle |
| Paddle / oar / fin | Paddlewheel, oar, paddle, oscillating fin, fluke | Cyclic or reciprocating reaction against water |
| Sail / kite | Aerodynamic sail, rigid wing sail, kite | Ambient wind produces force transmitted to body |
| Rotorcraft | Main rotor, multirotor, coaxial, tandem, intermeshing, cyclorotor | Rotating lifting system produces lift and/or thrust |
| Fixed/flapping wing | Powered fixed wing, ornithopter, flapping foil | Aerodynamic surfaces create lift/thrust with forward or cyclic motion |
| Breathing jet | Turbojet, turbofan, ramjet, pulsejet | Air is ingested; exhaust momentum creates thrust |
| Rocket | Solid, liquid, hybrid, cold-gas, monopropellant | Onboard working mass enables operation without atmospheric intake |
| Electric/plasma space | Ion, Hall, electrospray, plasma, electrothermal | Electrically accelerated working mass |
| Propellantless space | Solar sail, electric sail, magnetic/electrodynamic tether | External field or radiation interaction |
| Cable / tow / launch | Winch, funicular cable, towline, catapult, rail launch | Force supplied through external linkage or impulse |
| Magnetic linear | Linear motor, maglev propulsion | Electromagnetic force along guideway |
| Buoyancy modulation | Underwater glider, variable-buoyancy vehicle, balloon altitude cycling | Vertical force and environment generate horizontal progress |
| Mixed / redundant | Wheel plus propeller; sail plus engine; rotor plus wing; battery plus combustion | Multiple paths may be concurrent, alternate or emergency-only |

### 4.5 Steering, stopping, holding, and stability

| Function | Mechanisms |
| --- | --- |
| Directional control | Steered wheel/axle; skid steer; differential thrust; rudder; canard; thrust vector; sail trim; articulated body; body lean; control surface; variable geometry |
| Attitude / trim | Elevator/aileron/rudder; cyclic/collective; ballast/trim tanks; reaction wheel; control moment gyro; magnetorquer; movable mass; aerodynamic tabs |
| Speed reduction | Friction brake; regenerative brake; engine/compression brake; aerodynamic drag device; reverse thrust; propeller reversal; drogue; water brake |
| Stop / hold | Parking brake; pawl; chock; anchor; mooring; station keeping; hover; dynamic positioning; magnetic hold; geostationary/orbital station keeping |
| Stability | Passive geometry; suspension; keel; dihedral; fins; gyroscopic stabilization; electronic stability control; active suspension; flight controller |
| Emergency | Kill switch; emergency stop; dead-man control; failsafe neutral; parachute; autorotation; ditching; escape; safe-state shutdown; deorbit/reentry plan |

### 4.6 Differentiating examples required by the substrate

| Recipe | Support | Propulsion path | Control | Decisive distinction |
| --- | --- | --- | --- | --- |
| Electric scooter | Ground / wheels | Battery → motor → driven wheel | Handlebar/lean; friction + regen | Stand-on or seated micromobility platform |
| Fan-propelled bicycle | Ground / bicycle wheels | Engine or motor → air fan/propeller → air thrust | Front wheel/body lean; wheel brakes | Wheels support and steer; air—not the wheel—receives propulsive reaction |
| Airboat / fan-propelled boat | Water / displacement or planing hull | Engine or motor → air propeller/fan → air thrust | Air rudders, thrust vector or differential thrust | Hull is water-supported while propulsion reacts against air |
| Submerged-propeller boat | Water / hull | Engine or motor → submerged propeller → water thrust | Rudder, steerable drive, pods or differential thrust | Propulsor acts below the water surface against water |
| Waterjet boat | Water / hull | Engine or motor → pump/impeller → waterjet | Steerable nozzle/reversing bucket | Internal water-flow path and nozzle replace exposed propeller |
| Hovercraft | Surface / air cushion | Lift fan → pressure cushion; separate or shared thrust fan | Rudders, thrust vector, skirts | Support and propulsion can both use air but are separate flow paths |
| Amphibious propeller car | Ground wheels ↔ water hull | Wheel traction on land; water or air propulsor afloat | Mode-dependent wheel/rudder/thrust steering | Configuration and active movement path change at transition |
| Blimp | Air / aerostatic lift | Lift gas supports; motorized propellers provide thrust | Vectoring, fins, differential thrust, ballast/trim | Static lift is not motor propulsion |

# 5. Control regimes, autonomy, and responsibility

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.05 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:25a4891d5cb95add8e188a99824b825872095b017d0cd8233d8c94f6c35c959c

![Matrix with machine functions as rows and human, assistance, automation, and remote or fleet control as columns, with a note that authority and fallback are recorded per cell.](/substrate/v1.4.1/assets/media/image4.png)

Control state is a matrix over functions and time—not a marketing adjective attached to the whole vehicle.

Road automation, maritime autonomy, drones, industrial robots and RC vehicles use different terms because they allocate tasks and responsibility differently. RTracer should preserve external vocabularies but normalize them into a function-scoped ControlAssignment. One operation can combine an onboard driver, automated stability control, remote payload operator, fleet scheduler and emergency supervisor.

```text
Canonical control assignment
ControlAssignment(function, mode, controlling_actor, actor_location, authority_scope, command_form, command_link, dependency, operating_envelope, start/end, handover_trigger, fallback_actor, safe_state, evidence).
```

### 5.1 Controlled functions

| Function | Representative control scope |
| --- | --- |
| Propulsion / power | Start, enable, select source, command torque/thrust, limit output, shut down |
| Steering / attitude | Heading, trajectory, wheel angle, rudder, surfaces, trim, pose and articulation |
| Braking / stopping | Slow, stop, hold, park, anchor, moor, hover, station keep |
| Stabilization | Traction, yaw, roll, pitch, depth, altitude, suspension and load stability |
| Navigation | Localize, map, route, plan, follow waypoints, comply with traffic or right-of-way |
| Hazard response | Detect, classify, predict, avoid, yield, abort, escape and enter safe state |
| Formation / coupling | Tow, dock, couple, uncouple, consist control, leader/follower and swarm spacing |
| Payload / mission | Carry, manipulate, inspect, spray, film, race, serve, release or recover payload |
| Energy management | Charge/refuel, source selection, thermal control, reserve protection, load shedding |
| Configuration | Deploy gear, fold wing, transform mode, change geometry, select calibration or software |
| Communications | Link selection, identity, network participation, distress and traffic coordination |
| Maintenance / recovery | Self-test, diagnostics, degraded mode, return-to-base, rescue, deorbit or disposal |
| Social / commercial | Post, reply, invite, book, quote, sell or spend under a separate digital mandate |

### 5.2 Control mode vocabulary

| Mode | Meaning |
| --- | --- |
| Passive / no active control | Motion determined by environment, geometry or another system; may still have safety constraints |
| Direct mechanical | Human force or command linked mechanically to steering, braking, propulsion or tool |
| Powered direct | Human command amplified hydraulically, pneumatically or electrically without task automation |
| Onboard manual | Human aboard continuously performs the function |
| Rider balance / body control | Lean, weight shift, reins, harness or body movement is part of the command channel |
| Towed / pushed / carried | Prime mover or handler supplies trajectory and force through coupling or contact |
| Line-of-sight remote | Offboard human commands directly while visually observing the asset |
| FPV remote | Offboard human relies principally on onboard video or sensor view |
| Tethered remote | Command, power and/or data travel through a physical tether |
| Beyond-line-of-sight teleoperation | Remote command through a network with explicit latency, coverage and loss handling |
| Shared control | Human and automation concurrently shape the command |
| Driver/rider assistance | Automation supports a narrow function while human retains the broader task |
| Stabilized command | Human requests velocity/heading/attitude while lower loops maintain stability |
| Scripted sequence | Predefined commands execute without environmental task reasoning beyond guards |
| Waypoint / path following | Automation follows specified spatial or temporal targets |
| Task automation | System performs a bounded task while a human or parent system supervises |
| Conditional autonomy | System performs assigned functions only inside a defined operating envelope with fallback expectations |
| Supervised autonomy | System plans/acts; supervisor may approve, intervene or manage exceptions |
| Bounded autonomy | System performs specified functions and fallback within a validated envelope without continuous human control |
| Cooperative / negotiated | Humans and machines allocate tasks dynamically under explicit authority rules |
| Leader–follower | One vehicle, human or infrastructure source supplies goals or trajectory to followers |
| Swarm / distributed | Control emerges across multiple agents with local and/or central coordination |
| Infrastructure-controlled | Guideway, traffic system, launch controller or site system allocates movement |
| Fleet-scheduled | Fleet service assigns missions; local controller handles movement within scope |
| Environmental / reflexive | Mechanical or control response follows wind, current, gravity or local stimulus |

### 5.3 Actor, location, command, and link facets

| Facet | Controlled vocabulary seed |
| --- | --- |
| Controlling actor | rider; driver; pilot; helmsman; crew; remote operator; payload operator; instructor; supervisor; dispatcher; infrastructure; onboard controller; fleet agent; peer vehicle |
| Actor location | on/in vehicle; riding externally; beside vehicle; visual range; local control room; remote center; moving chase/carrier platform; distributed |
| Command form | force/displacement; discrete switch; proportional command; velocity; heading/attitude; trajectory; waypoint; task; goal; policy; schedule; exception approval |
| Command path | mechanical; hydraulic; pneumatic; electrical analog; wired digital; radio; cellular/IP; satellite; optical; acoustic; tether; indirect infrastructure signal |
| Link properties | directionality; bandwidth; latency/jitter; range; availability; encryption; authentication; redundancy; interference tolerance; loss behavior |
| Authority | observe; advise; limit; veto; command; override; emergency stop; configure; release payload; move; couple; spend; publish |
| Dependency | none; optional aid; required for start; required continuous; periodic check-in; exception-only; fallback-only |
| Handover | request; readiness; acknowledgement; transfer time; minimum-risk condition; unsuccessful handover response |

### 5.4 Operating envelope and fallback

- Record the validated domain, route or geofence; terrain/surface; speed; altitude/depth; weather; visibility; traffic; connectivity; payload; configuration; map quality; lighting; and time constraints.

- Record entry/exit conditions, monitoring method, degradation thresholds, prohibited states and whether the system can recognize that it is outside the envelope.

- Fallback is an executable responsibility: actor, trigger, response time, safe state, stop/hold/return/recovery behavior and evidence from tests.

- Control can change during an operation. Every transition records old assignment, new assignment, trigger, acknowledgement, configuration and outcome.

- Separate physical control from social and commercial agency. Permission to publish telemetry never grants permission to move, book, buy, sell or spend.

### 5.5 External autonomy vocabularies

Preserve source labels as ExternalClassification records. SAE J3016 applies to sustained on-road driving automation; IMO’s maritime work classifies ship functions and modes; EASA categories classify operational risk; NIST ALFUS uses mission complexity, environmental difficulty and human independence. They are useful mappings, not one universal ladder.

# 6. Utility, mission, payload, and action

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.06 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:c6e646f3c52e0f6dd2d1b00b4ee2b04b02ba89bda1784057958a70102bacab4a

Mobility is only one capability. RTracer must describe what a machine can do, to what target, with which tool or payload, under which conditions, at what capacity and quality, and with what hazards. A capability is a qualified claim—not a permanent promise that the machine is ready, authorized, legal or safe for every use.

```text
Capability grammar
Capability = verb + object/target + mechanism + input/output + capacity/rate/precision + operating envelope + prerequisites + hazards + configuration + evidence.
```

| Mission family | Representative verbs and outputs |
| --- | --- |
| Conveyance | carry, transport, shuttle, accommodate, evacuate, shelter people, animals, cargo, fluids, energy, data or another vehicle |
| Logistics | pick up, deliver, sort, stage, load, unload, transfer, dispatch, replenish and return |
| Tow / push / recover | tow, push, pull, winch, salvage, recover, escort, tug, reposition and rescue |
| Lift / handle | lift, lower, hoist, stack, place, rotate, clamp, grip, fork, sling, crane and stabilize loads |
| Manipulate | reach, grasp, assemble, disassemble, turn, press, connect, disconnect, service and repair |
| Excavate / construct | dig, drill, bore, cut, grade, trench, compact, pave, demolish, print, weld and build |
| Agriculture / forestry | plough, seed, plant, cultivate, irrigate, spray, mow, harvest, bale, fell, forward and process |
| Mine / extract | drill, blast-support, cut, load, haul, crush, sample and ventilate |
| Clean / maintain | wash, sweep, scrub, vacuum, deice, decontaminate, coat, polish, inspect and maintain infrastructure |
| Pump / distribute | pump, meter, mix, spray, spread, discharge, refuel, recharge, ventilate and suppress |
| Sense / inspect | observe, image, film, scan, map, survey, sample, measure, diagnose, detect and monitor |
| Communicate / relay | broadcast, relay, beacon, synchronize, host network service and provide navigation reference |
| Generate / supply | generate, store, convert and distribute electrical, hydraulic, pneumatic, thermal or mechanical power |
| Emergency / medical | respond, rescue, fight fire, provide medical care, transport casualty, search, contain and warn |
| Science / space service | experiment, sample, deploy, rendezvous, dock, service, refuel, observe, land, ascend and return |
| Racing / training | race, time, pace, coach, simulate, demonstrate, test and certify operator skill |
| Media / entertainment | perform, appear, animate, film, stream, display, tour, create effects and host an audience |
| Habitation | provide berth, cabin, life support, climate, sanitation, food preparation and protected workspace |
| Security / regulated protection | patrol, guard, detect, interdict or provide regulated protective capability under explicit law and authority |

### Payload and work-target model

| Object | Required distinctions |
| --- | --- |
| Occupant | crew, operator, passenger, trainee, patient, animal; seat/berth/restraint/life-support/accessibility needs |
| Cargo | piece, bulk, liquid, gas, temperature-controlled, hazardous, live, high-value, oversized or containerized |
| Mission payload | sensor, camera, communications relay, scientific instrument, medical unit, deployed robot or demonstrator |
| Tool / end effector | bucket, blade, fork, gripper, drill, cutter, sprayer, pump, manipulator, winch, crane or show effect |
| Consumable load | fuel, oxidizer, water, seed, treatment chemical, extinguishing agent, ballast or feedstock |
| Work target | surface, material, object, organism, infrastructure element, environment, another vehicle or digital/physical service request |
| Mounting + services | location, orientation, restraint, mechanical interface, power, data, fluid, cooling, protection and custody |
| Configuration impact | mass, center of gravity, inertia, drag, trim, stability, clearance, energy use, range, control and approvals |

### Capability state must stay orthogonal

- Designed capability: present in an engineering definition.

- Realized capability: installed in the current configuration.

- Available capability: healthy, supplied and not inhibited.

- Authorized capability: allowed for this actor, place, time and mission.

- Engaged capability: active now under a control assignment.

- Executed capability: produced an observed result with a receipt.

# 7. Systems, parts, components, materials, and interfaces

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.07 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:333cfcaec28ffc71d7733840e72ba2b85e337aa35cee7e68972255d414169979

A universal parts model needs several simultaneous structures. The same pump can be a product inside an assembly, a functional provider of pressure, a spatial object in a bay, a node on an electrical and fluid network, a maintenance item and a safety barrier. One mutable parent_component_id cannot represent that reality.

```text
Four-aspect discipline
Maintain product/composition, function, location, and type views, then add flow, control, maintenance, safety, ownership and certification views as relationships. A part can play several roles without changing its identity.
```

### 7.1 Universal system catalog

| System family | Includes |
| --- | --- |
| Identity + markings | plates, serial marks, transponders, colors, livery, labels and visible identity |
| Primary structure | frame, chassis, monocoque, airframe, hull, pressure vessel, envelope, backbone and joints |
| Body + enclosure | cab, cabin, body, fairing, shell, armor, weather enclosure, doors, hatches and glazing |
| Support interface | wheels, tires, tracks, skids, skis, legs, rail gear, hull, foils, wings, rotors, envelope and tether |
| Suspension + isolation | springs, dampers, bogies, active suspension, vibration isolation and leveling |
| Lift + buoyancy | wings, rotors, lifting surfaces, envelope/gas cells, ballonets, ballast, foils and cushion system |
| Propulsion | engines, motors, turbines, propulsors, fans, rotors, jets, rockets, sails, paddles and traction drives |
| Resource storage | fuel/oxidizer tanks, batteries, capacitors, pressure vessels, accumulators, feedstock and working mass |
| Resource feed | pumps, lines, valves, regulators, injectors, manifolds, intakes and filters |
| Power conversion | engines, motors, generators, fuel cells, power electronics, turbines and thermal converters |
| Transmission | clutch, gearbox, CVT, differential, shafts, joints, chain, belt, hydraulic/pneumatic and electrical distribution |
| Steering + guidance actuation | steering gear, articulated joints, rudders, control surfaces, thrust vectoring and trim devices |
| Braking + holding | friction/regenerative brakes, retarders, anchors, mooring, arresting, parking and station keeping |
| Stability + attitude | keels, stabilizers, fins, anti-roll, reaction wheels, control moment gyros, ballast and active control |
| Work actuation | hydraulic, pneumatic, electric and mechanical actuators; manipulators and tool drives |
| Tool / end effector | bucket, blade, fork, gripper, drill, cutter, mower, sprayer, winch, crane and mission mechanism |
| Payload + cargo | bays, racks, mounts, restraints, containers, tanks, seats, berths and handling systems |
| Sensing + metrology | position, motion, environment, force, pressure, temperature, imaging, ranging and condition sensors |
| Navigation + timing | GNSS, inertial, odometry, maps, beacons, clocks, celestial, magnetic, acoustic and terrain matching |
| Control + computing | controllers, flight/vehicle computers, safety PLCs, domain controllers, storage and edge compute |
| Data networks | buses, gateways, switches, wiring, fiber, wireless links, protocols and diagnostic interfaces |
| Communications | radio, cellular, satellite, acoustic, optical, antennas, modems, remote ID and traffic transponders |
| Electrical | generation, distribution, conversion, grounding, protection, harnesses, connectors and loads |
| Hydraulic + pneumatic | reservoirs, pumps, compressors, accumulators, valves, lines, actuators and conditioning |
| Thermal | cooling, heating, insulation, heat exchangers, radiators, cryogenic management, HVAC and deicing |
| Lubrication | reservoir, pump, distribution, filtration, cooling and monitoring |
| Intake + exhaust | air intake, filtration, combustion air, exhaust, aftertreatment, venting and plume management |
| Environmental control | pressurization, ventilation, air quality, humidity, life support and contamination control |
| Crew + human interface | controls, displays, seats, restraints, access, visibility, accessibility, bridge/cockpit and remote station |
| Safety + survival | fire protection, emergency stop, guarding, containment, parachute, flotation, evacuation and rescue |
| Lighting + signaling | illumination, navigation lights, indicators, horn, siren, markers and conspicuity |
| Coupling + docking | hitch, fifth wheel, coupler, towline, docking ring, latches, launch/recovery and refuel interfaces |
| Ground / site support | jacks, stands, chocks, mooring, transport fixtures, chargers, fueling and test equipment |
| Service + diagnostics | test points, condition monitoring, built-in test, access panels, tooling and maintenance data |
| Finish + character | paint, wrap, coating, trim, interior, livery, lighting effects, sound and persona-linked appearance |
| Software + data | firmware, applications, maps, AI models, rules, keys, calibration, parameters and content canon |

### 7.2 Trackable item kinds

| Kind | Identity and lifecycle behavior |
| --- | --- |
| DesignDefinition | Make/model/part/revision and intended characteristics; not a physical object |
| Serialized instance | Unique physical part with installation, custody, condition, meter and repair history |
| Lot / batch occurrence | Group identity for manufactured material or parts with shared provenance |
| Bulk material | Quantity-managed material whose individual units are not tracked |
| Consumable | Fuel, fluid, filter, tire compound, coating, propellant, gas, lubricant or treatment material consumed or depleted |
| Life-limited item | Tracks cycles, hours, distance, starts, pressure events, fatigue or calendar limit |
| Software artifact | Versioned executable, library, operating system, map, AI model, rule set or data package |
| Calibration set | Parameters and learned/adapted values tied to hardware, software, procedure and approval |
| Material specimen | Sample or coupon with chain of custody and test results |
| Tooling / support equipment | Fixture, charger, diagnostic tool, ground support, mold or transport cradle |
| Temporary payload | Installed for an operation with services, mass properties, custody and removal event |

### 7.3 InterfacePort and Connection

| Port family | Compatibility attributes |
| --- | --- |
| Mechanical load | geometry, mating standard, degrees of freedom, load paths, torque, preload, retention, wear and environment |
| Structural joint | weld, bond, rivet, bolt, clamp, hinge, bearing, composite joint and inspection requirements |
| Electrical power | voltage, current, frequency, phases, polarity, grounding, protection, connector and isolation |
| Electrical signal | pinout, level, impedance, timing, shielding, diagnostic and failure behavior |
| Data / control | physical layer, protocol, role, direction, bandwidth, latency, address, security and version |
| Fluid | medium, phase, pressure, temperature, flow, cleanliness, material compatibility, coupling and leakage class |
| Gas / air | composition, pressure, flow, filtration, drying, toxicity/flammability and venting |
| Thermal | heat-load direction, resistance/conductance, temperature range, coolant and contact geometry |
| Optical | wavelength, aperture, alignment, power, modulation and contamination control |
| RF | frequency, bandwidth, power, antenna, pattern, polarization, emissions and authorization |
| Acoustic | medium, frequency, source/sensor level, geometry, coding and propagation limits |
| Human | reach, force, visibility, accessibility, cognitive load, control/display convention and protection |
| Cargo / occupant | envelope, mass, restraint, access, environment, compatibility and emergency release |
| Software / service | API, schema, authentication, authorization, rate, error semantics and compatibility |

### Flow networks

- Represent structural load, mechanical power, electrical power, fluid/material, thermal, information, command, exhaust/waste, people/cargo and rights/custody flows separately.

- Composition must be acyclic inside one snapshot. Energy, fluid, thermal, data and control networks may contain registered cycles.

- A Connection is a dated realized relationship between compatible ports. It records state, orientation, routing, protection, tests and disconnection history.

- Unknown extension ports and vendor concepts are preserved in namespaced vocabularies; they never collapse to a lossy ‘other.’

# 8. Configuration, coupling, transformation, and formation

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.08 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:739750146e14aea19a47d3ca0eb1221f7e30c8b798983c426775eb8194bd639c

The asset is durable; its build is not. Every operation, telemetry segment, test, incident, content claim and valuation should reference the exact configuration active when known. Immutable snapshots make the whole lifespan reconstructable without freezing innovation.

| Configuration view | Question answered |
| --- | --- |
| As-designed | What did the approved design intend? |
| As-manufactured | What did production actually build? |
| As-delivered | What entered custody at handover? |
| As-maintained | What does the service record say is installed? |
| As-observed | What inspection, scan or sensor evidence indicates? |
| As-tested | What exact build and conditions produced a result? |
| As-operated | What build, load, software, control regime and mode were used? |
| As-presented | What public projection is intentionally shown? |

### ConfigurationSnapshot minimum

- root asset, predecessor snapshot, creating change event, effective interval and content digest

- installed component occurrences, positions, orientations, joints, ports, connections and current topology

- software, firmware, maps, AI models, calibrations, parameters, credentials and enabled features

- geometry, transformation state, dimensions, mass, center of gravity, inertia, balance, ballast and trim

- consumables, fluids, tire/track/propeller/sail/tool state, payload, occupancy and restraints where permitted

- active energy, support, propulsion, control, action, communication and safety graphs

- derived capabilities, limits, incompatibilities, approvals, competition class and operating-envelope locks

- domain-pack and vocabulary version lock so the snapshot remains interpretable later

### Assembly and coupling relationships

| Relationship | Examples | What must be recorded |
| --- | --- | --- |
| Installed / mounted | Engine, battery, sensor, payload, tool | position, orientation, role, fasteners/joints, interfaces and effectivity |
| Contained / carried | Cargo, nested rover, vehicle on transporter | restraint, environment, custody, load transfer and deployability |
| Hitched / coupled | Trailer, railcar, implement, sidecar | joint type, degrees of freedom, loads, brakes, power/data/fluid and lock state |
| Towed / pushed | Barge, glider, disabled car, consist | force path, control allocation, tow geometry, limits and emergency release |
| Docked / berthed | Vessel, spacecraft, drone station | capture, seal, structural, power, fluid, data and authority state |
| Stage / stack | Rocket stages, boosters, payload adapter | separation logic, pyrotechnic/mechanical interfaces, consumed/recovered outcomes |
| Formation | Convoy, platoon, flight, swarm | membership, leader/dispatcher, relative geometry, communications and control allocation |
| Host / deployed | Mothership plus drone, aircraft plus probe | carried state, release/recovery conditions, delegated mission and custody |

### Transformation and mode change

A folding wing, retractable gear, deployable sail, track-to-wheel module, road-to-water transition, stage separation or humanoid transformation changes geometry and often changes topology, mass properties, support, propulsion, control and legal status. Model a TransformationDefinition plus a performed TransformationEvent, preconditions, intermediate hazards, resulting snapshot and reversibility.

```text
Formation identity rule
A train consist, tractor-trailer combination, tug-and-tow, launch stack, swarm or docked spacecraft can receive a temporary assembly identity and history. Membership never merges the identities, rights, evidence or service histories of its members.
```

# 9. Modifications, maintenance, repair, care, and whole-life history

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.09 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:27f9fbb3fc3e1fddbea294b48a9bb65845303611c69e4f551cb909eaf4c673bc

RTracer should preserve intent, work, evidence and outcome. A modification is a controlled transition between configurations. Maintenance restores or preserves intended function. Repair addresses damage or failure. Care protects appearance or condition. Temporary setup changes and payload swaps may alter the as-operated configuration without becoming permanent modifications.

| Change class | Purpose | Configuration consequence |
| --- | --- | --- |
| Maintenance | Prevent, inspect, adjust, service or replace to preserve intended state | May create a new snapshot when installed items, software, settings or condition materially change |
| Repair | Restore after damage, defect or failure | Records damage, repair design, actual work, inspections and residual limits |
| Modification | Intentionally alter capability, performance, appearance, interfaces or compliance | Always produces an auditable before/after diff |
| Overhaul / rebuild | Disassemble, renew and re-establish condition or life | Component identity and life-reset policy stay explicit |
| Temporary setup | Race, test, mission, weather or transport setup | Time-bounded snapshot; may revert without erasing history |
| Payload / consumable change | Load, unload, refuel, recharge, change ballast, tire, propellant or tool | As-operated load and resource state update |
| Software / calibration | Patch, reflash, remap, tune, enable, disable or parameterize | Versioned artifact and calibration diff; approvals and rollback retained |
| Care / cosmetic | Wash, detail, polish, protect, wrap, paint, preserve or display | Condition/media event; snapshot if finish or livery changes |

### 9.1 Modification operation vocabulary

| Verb family | Seed terms |
| --- | --- |
| Composition | add/install; remove; replace like-for-like; substitute alternate; swap; couple; decouple; stage; integrate |
| Placement | relocate; reorient; reposition; reroute; repackage; redistribute; reballast |
| Geometry | resize; reshape; extend; shorten; widen; narrow; fold; retract; deploy; cut; drill; machine; print; cast |
| Joining | bolt; rivet; weld; braze; solder; bond; clamp; press-fit; stitch; seal; reinforce |
| Mechanical | regear; rebearing; align; balance; tension; preload; respring; redamp; lighten; strengthen; derate/uprate |
| Electrical | rewire; repin; add circuit; change voltage; isolate; ground; fuse; convert; update harness or power electronics |
| Fluid / thermal | replumb; change medium; reroute line; resize duct; add cooler/heater; insulate; vent; pressurize; seal |
| Propulsion / energy | engine/motor swap; fuel conversion; battery conversion; hybridize; change propulsor; tune power; add regeneration |
| Control / software | remap; reflash; patch; roll back; recalibrate; recode; retrain; configure; enable; disable; change limits |
| Surface / appearance | paint; wrap; coat; plate; anodize; polish; texture; livery; lighting; sound; character treatment |
| Repair / restore | repair; rebuild; overhaul; remanufacture; replace material; straighten; patch; preserve; conserve; reproduce |
| Status | propose; engineer; submit; approve; acquire; install; inspect; test; accept; return-to-service; reject; defer; revert |

### 9.2 Modification package

- baseline configuration, intended outcome, requirements, design definition, approved data and planned diff

- actual parts, material lots, software, calibration, tools, procedures, workers, facility and deviations

- affected systems, functions, ports, networks, safety barriers, documentation and continuing maintenance instructions

- impact vector: mass/CG/inertia, dimensions, loads/fatigue, energy/range, thermal, handling/stability, braking, emissions/noise, reliability and maintainability

- regulatory, competition, warranty, insurance, cybersecurity, privacy, licensing, value and transfer consequences

- inspection, measurement, test, conformity, release-to-service, operating limitations, rollback and evidence

- resulting immutable configuration snapshot and public/private story artifacts

### 9.3 Maintenance and condition record

| Record area | Required detail |
| --- | --- |
| Trigger | calendar, distance, hours, cycles, starts, pressure events, energy throughput, condition, fault, recall, incident or operator observation |
| Planning | task definition, due rule, tolerance, prerequisites, parts/tools, skills, facility, safety isolation and downtime |
| Inspection | area/item, method, access, measurement, acceptance criteria, finding, severity, evidence and inspector |
| Diagnosis | symptom, test sequence, fault code, hypotheses, root cause, contributing factors and uncertainty |
| Work | clean, lubricate, adjust, tighten, align, replace, repair, overhaul, calibrate, update, test and close |
| Resources | labor, provider, tools, parts, material lots, fluids, energy, costs, warranty and disposal |
| Outcome | condition after, remaining defect, deferral, limitation, next due, readiness, release and new configuration |
| Reliability | failure mode, cause, mechanism, consequence, detection, downtime, corrective action and recurrence |

### 9.4 Care, wash, appearance, and preservation

A car-wash photo belongs in a structured care event, not only in a social gallery. Record before/after media, wash/detail method, products and material compatibility, area treated, observed defects, paint/wrap/coating condition, provider, weather/location privacy, cost, rights, and any protection applied. The same pattern covers hull cleaning, aircraft wash, decontamination, corrosion control, envelope care, model-car cleaning and museum preservation.

### 9.5 Lifecycle states and dispositions

| Axis | States |
| --- | --- |
| Creation | concept, design, prototype, test article, manufactured, assembled, delivered, commissioned |
| Use | active, ready, dispatched, operating, reserve, degraded, limited, grounded/laid-up/withdrawn |
| Custody | owned, leased, financed, entrusted, stored, transported, displayed, impounded or abandoned |
| Preservation | stored, mothballed, conserved, museum/display, restoration in progress |
| End state | decommissioned, parted out, scrapped, recycled, destroyed, consumed, lost, unrecovered, archived |
| Re-entry | reactivated, recommissioned, restored, rebuilt or recovered under explicit continuity policy |

# 10. Measurements, tests, performance, health, failure, and safety

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.10 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:718ad6726d171091b9606d1563012106f65d616ef93991790d4adf9034c5a6e5

A number without quantity kind, unit, reference condition, coordinate frame, configuration and method is not reusable vehicle data. The substrate must preserve the source value and uncertainty, then record every conversion or derivation.

```text
Measurement record
quantity_kind, original value/unit, normalized value/unit, scalar/vector/tensor/distribution form, tolerance/uncertainty, method, reference conditions, coordinate frame/datum, timebase, instrument/sensor, calibration, configuration, quality flags, evidence.
```

| Quantity family | Examples |
| --- | --- |
| Geometry | length, width, height, wheelbase, track, gauge, draft, beam, span, area, volume, clearance, articulation and transformed envelope |
| Mass properties | mass, payload, axle/wheel loads, displacement, center of gravity/buoyancy, inertia, balance and ballast |
| Kinematics | position, attitude, velocity, acceleration, angular rate, jerk, slip, climb, sink, turn and trajectory error |
| Loads + structure | force, torque, pressure, strain, stress, fatigue cycles, vibration, shock, impact and deflection |
| Energy + resources | power, energy, fuel/oxidizer, state of charge/health, current, voltage, pressure, flow, consumption and recovery |
| Propulsion | shaft/wheel/hub/propeller/rotor/jet thrust or power, torque curve, efficiency, slip, wake and byproducts |
| Performance | speed, acceleration, braking, range, endurance, grade, drawbar pull, lift, payload, throughput, precision and duty cycle |
| Thermal | temperature, heat flow, cooling capacity, thermal margin, icing, cryogenic state and environmental exchange |
| Environmental | air/water density, pressure, wind, current, sea state, terrain, visibility, precipitation, radiation, dust and contamination |
| Acoustic + vibration | sound pressure/power, frequency spectrum, cabin exposure, structural vibration and signature |
| Control + communication | latency, jitter, bandwidth, packet loss, tracking error, stability margin, response time and intervention performance |
| Reliability + health | usage counters, wear, degradation, fault rate, probability, remaining life, availability, downtime and confidence |
| Impact | emissions, exhaust constituents, noise, wake, erosion, waste, energy source, recyclability and operational footprint |

### 10.1 Universal test record

- test intent, procedure/revision, requirements and acceptance criteria

- test article, exact configuration, control regime, software/calibration, operator and facility

- environment, load, resource state, setup geometry, instruments, calibrations, channels and sampling/time synchronization

- raw dataset digests, transformations, corrections, formulas, uncertainty and excluded data

- results, pass/fail/indeterminate disposition, anomalies, reviewer, approvals, limitations and retest links

### 10.2 Dyno and power tests are not car-only

| Test family | What must remain contextual |
| --- | --- |
| Engine / motor bench | converter shaft torque, speed, power, efficiency, temperatures, flow and emissions |
| Chassis / wheel dyno | wheel/roller power and torque with tire, gearing, losses, correction method and restraint setup |
| Hub dyno | output at hubs, bypassing tire/roller interface |
| Propeller / rotor stand | thrust, torque, RPM, electrical/fuel input, airflow, noise and efficiency |
| Marine bollard / tow-tank | static thrust, pull, speed-resistance, propulsor/hull interaction and water conditions |
| Jet / rocket static test | thrust-time, chamber/feed state, impulse, mixture, temperatures, vibration and safety disposition |
| Rail / drawbar | tractive effort, adhesion, power, braking and wheel-rail conditions |
| Hydraulic / tool bench | pressure-flow, force/speed, efficiency, leakage, temperature and duty cycle |
| Battery / fuel-cell cycle | capacity, energy, power, impedance, degradation, thermal behavior and safety limits |

### 10.3 Failure, incident, and hazard model

| Layer | Required distinctions |
| --- | --- |
| Fault / defect | Observed nonconformity or abnormal state; source, detection, duration and confidence |
| Failure mode | How a function was lost, degraded, intermittent, unintended or unsafe |
| Mechanism / cause | Physical, software, environmental, human, organizational, maintenance or unknown causal factors |
| Effect / consequence | Local, system, mission, occupant, public, environmental and economic outcomes |
| Incident | Bounded occurrence with operation, configuration, actors, conditions, evidence and reporting status |
| Hazard | Potential harm, exposed targets, severity, likelihood, controls, residual risk and owner |
| Barrier / safeguard | Prevention, detection, containment, mitigation, recovery and independent safety path |
| Corrective action | Contain, repair, modify, inspect fleet, update procedure/software, monitor and verify effectiveness |

### Safety and recovery families

- safe stop, parking, hold, anchor, moor, loiter, hover, surface, land, return-to-base, controlled descent, abort, shutdown and isolate

- emergency stop, dead-man input, independent supervisor, actuator isolation, geofence, speed/force/energy limits and collision protection

- escape, evacuation, flotation, parachute, autorotation, fire suppression, rescue access, distress signaling and life support

- recovery vehicle, tow, salvage, retrieval, deorbit, passivation, disposal, quarantine and environmental remediation

# 11. Operating domains, paths, environments, and transitions

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.11 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:011a9947c764c8ac83ee9cca6bd5f87cf1dc0d58af53148405d5afce0d505d02

The domain is not merely ‘land, sea or air.’ It is the physical medium, support condition, infrastructure, environmental envelope, traffic context, mission boundary and legal operating area in which a capability and control regime are valid.

| Domain | Defining variables |
| --- | --- |
| Prepared solid surface | road, lane, runway, floor, deck, paved site, track surface |
| Unprepared terrain | soil, sand, rock, mud, vegetation, rubble, slope, dune and planetary regolith |
| Snow / ice | packed snow, powder, glacier, ice sheet, frozen waterway and groomed route |
| Rail / guideway | rail gauge, loading gauge, rack, monorail, magnetic guideway, slot, groove or automated guide |
| Cable / suspended path | aerial ropeway, funicular cable, elevator shaft, zipline or crane cable |
| Surface water | river, lake, harbor, canal, coastal and ocean; displacement, planing, foiling or cushion state |
| Submerged water | water column, depth/pressure, salinity, current, acoustic environment and navigation constraints |
| Seabed / benthic | bottom contact, sediment, slope, obstacles, tether and pressure |
| Atmosphere | airspace, altitude, density, wind, weather, icing, visibility, obstacle and traffic context |
| Ground effect / near surface | wing-in-ground, hover cushion, rotor downwash and terrain/water interaction |
| Near-space / high altitude | low density, radiation, thermal cycling, communications and recovery |
| Space / orbit | vacuum, gravity regime, orbit, radiation, thermal, debris, attitude and communications |
| Planetary surface | gravity, terrain, dust, atmosphere, illumination, temperature and communications delay |
| Subsurface void | mine, tunnel, cave, sewer, duct, building cavity and confined-space hazards |
| Pipe / borehole | diameter, bend radius, fluid, pressure, access, tether and inspection target |
| Soil / rock | burrowing, drilling and excavation with material mechanics and support requirements |
| On-body / wearable | human interface, biomechanics, fit, assistive load, safety and dignity boundary |
| Host-carried | inside/on another vehicle, launch/release/recovery envelope and service interfaces |

### Path and infrastructure constraint

- free-ranging; lane/road constrained; rail/guideway constrained; cable constrained; pipe/duct constrained; wall/ceiling attached; geofenced; orbital; convoy/formation constrained; carrier constrained

- record gauge, loading envelope, axle/load limits, clearance, berth/dock, runway/landing zone, charging/refueling, communications and navigation infrastructure compatibility

- distinguish physical capability, declared compatibility, observed access, owner permission and regulatory authorization

### Operating-envelope dimensions

| Envelope family | Representative limits |
| --- | --- |
| Geometry + surface | terrain class, roughness, slope, step, gap, depth, clearance, turning space, gauge, loading envelope |
| Atmosphere + weather | temperature, pressure, density, wind, precipitation, visibility, lightning, icing and contamination |
| Marine | depth, water density/salinity, current, wave/sea state, tide, ice, turbidity and seabed |
| Space / planetary | gravity, orbit, vacuum, radiation, dust, illumination, thermal cycle, debris and communication delay |
| Traffic + exposure | traffic classes/density, mixed human/machine interaction, population exposure and right-of-way rules |
| Infrastructure | map/beacon/GNSS quality, road/rail/waterway/airspace, charging/refueling, docking and control services |
| Configuration + load | mass, center of gravity, dimensions, payload, occupants, energy reserve, software and health |
| Mission + time | permitted actions, route/geofence, duration, schedule, season, daylight and authorization window |
| Fallback feasibility | safe stop/hold/anchor/land/surface/return/recover locations, communications and responder access |

### Transition record

Road-to-water, surface-to-submerged, land-to-air, atmosphere-to-space, host-carried-to-independent, docked-to-free, wheel-to-track and folded-to-deployed transitions are first-class operations. Record entry conditions, configuration/topology change, active support and propulsion paths, control handover, safety gates, intermediate state, outcome and evidence.

# 12. Canonical vehicle-family and differentiating-domain catalog

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.12 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:c0b41d9f134af1d7a21d98b84af12bd970c2437cf0a9ed1691f5f8605d2b1bff

```text
How to use this catalog
Each row is a discoverable TypeRecipe, not a mutually exclusive database class. An asset may match several rows, and every row can branch by energy, scale, control, body, mission, configuration and jurisdiction. Novel combinations remain valid even before they receive a public name.
```

This catalog deliberately spans full-size, model, passive, ambient-powered, crewed, remote, autonomous, infrastructure-bound, transformable and utility machines. It is broad enough to seed search and onboarding while the universal facets keep the system open to the effectively infinite combination space.

### 12.1 Human-scale, assistive, cycle, and micromobility

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Handcart / pushcart | Ground; wheels/casters | Human push or pull | Passive cargo conveyance controlled through handle force |
| Stroller / pram | Ground; small wheels | Human push | Passenger conveyance for child with restraint and caregiver control |
| Litter / stretcher carrier | Ground or carried | Human carried, wheeled or vehicle-mounted | Patient/person transport with medical and handling constraints |
| Manual wheelchair | Ground; large/small wheels | Occupant hand-rim or attendant push | Assistive mobility; human remains rights principal, never component |
| Powered wheelchair | Ground; wheels/tracks | Battery-electric wheel/track drive | Assistive seating, accessibility, stability and control envelope |
| Sports / racing wheelchair | Ground; optimized wheels | Human arm power | Competition geometry, classification and performance specialization |
| Mobility scooter | Ground; three/four wheels | Battery-electric wheel traction | Seated personal accessibility platform with tiller or alternative control |
| Kick scooter | Ground; two+ wheels | Human kick / gravity | Stand-on narrow deck; wheel support and handlebar steering |
| Electric scooter | Ground; two+ wheels | Battery → motor → wheel traction | Stand-on/seated micromobility distinguished by electric driven wheel |
| Bicycle | Ground; usually two wheels | Human pedal → chain/belt/shaft → wheel | Balance/steering plus pedal traction |
| Pedelec / e-bike | Ground; bicycle wheels | Human pedal plus electric assistance | Electric support coupled to pedaling under a declared assistance policy |
| Throttle e-bike | Ground; bicycle wheels | Electric wheel traction with independent throttle | Motor command need not be coupled to pedaling |
| Combustion motorized bicycle | Ground; bicycle wheels | Small engine → wheel | Bicycle architecture with added combustion power path |
| Fan-propelled bicycle | Ground; bicycle wheels | Motor/engine → air propeller/fan | Wheels support/steer while thrust reacts against air |
| Cargo bicycle | Ground; two/three/four wheels | Human/electric wheel traction | Extended cargo platform, box or trailer-like load geometry |
| Tandem / multi-rider cycle | Ground; wheels | Multiple human inputs, optional electric | Several riders share one cycle power and control architecture |
| Recumbent cycle | Ground; wheels | Human/electric wheel traction | Reclined rider geometry changes visibility, aero and control interface |
| Tricycle / quadricycle | Ground; three/four wheels | Human/electric/combustion traction | Cycle-derived platform with static lateral support |
| Velomobile | Ground; wheels | Human/electric traction | Cycle mechanics enclosed by aerodynamic/weather body |
| Handcycle | Ground; wheels | Human arm crank, optional electric | Upper-body propulsion and accessibility configuration |
| Pedal kart / pedal car | Ground; four wheels | Human pedals → wheel traction | Low four-wheel recreational/utility cycle |
| Skateboard / longboard | Ground; trucks/wheels | Human push, gravity | Board platform steered by lean through trucks |
| Electric skateboard | Ground; small wheels | Battery-electric wheel/belt/hub drive | Handheld/body control on lean-steered board |
| Single-wheel board | Ground; one driven wheel | Battery-electric; active balance | Rider platform around one wheel requires stabilization control |
| Self-balancing two-wheel board | Ground; coaxial wheels | Battery-electric; active balance | Body lean command and electronic stabilization |
| Personal transporter | Ground; two+ wheels | Battery-electric; active balance | Upright platform with handle/control column or hands-free variant |
| Roller skate / powered skate | Ground; foot-mounted wheels | Human stride or compact electric drive | Wearable mobility interface attached to each foot |
| Gravity racer / soapbox | Ground; wheels | Gravity/coasting | No onboard conversion; controlled downhill vehicle |
| Land yacht | Ground; wheels | Wind → sail → rolling motion | Ground support with aerodynamic ambient propulsion |
| Iceboat / ice yacht | Ice; runners | Wind → sail | Low-friction runners support while sail reacts against air |
| Ski-bike / snow cycle | Snow/ice; skis and/or driven track | Gravity, human or motor | Cycle-like control adapted to snow support |
| Snowmobile | Snow; skis + track | Engine/motor → driven track | Skis steer while continuous track propels |
| Personal tracked carrier | Ground/snow; compact tracks | Electric/combustion track drive | Stand-on or seated personal platform using continuous traction |
| Animal-drawn cart / carriage | Ground; wheels/runners | Animal pull through harness | Animal actor supplies force and control relationship without becoming a component |
| Sleigh / toboggan | Snow/ice; runners/body | Gravity, human/animal tow | Sliding support with passive or external propulsion |

### 12.2 Powered road, passenger, freight, and special-purpose vehicles

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Moped | Road; two/three wheels | Pedal-assisted or small motor wheel traction | Low-power road cycle category varies by jurisdiction |
| Motor scooter | Road; two/three wheels | Combustion/electric wheel traction | Step-through chassis and scooter rider architecture |
| Motorcycle | Road/off-road; two wheels | Combustion/electric wheel traction | Rider-straddled powered single-track vehicle |
| Sidecar combination | Road; motorcycle + sidecar wheel | Motorcycle traction | Asymmetric coupled assembly carries passenger/cargo |
| Powered trike | Road; three wheels | Combustion/electric traction | Motorcycle/automotive controls on three-wheel support |
| Powered quadricycle / microcar | Road; four wheels | Electric/combustion traction | Small/light road vehicle distinct from full passenger-car classes by rules |
| Hatchback | Road; four+ wheels | Any road powertrain | Passenger body with rear liftgate and shared cargo/cabin volume |
| Sedan / saloon | Road; four+ wheels | Any road powertrain | Passenger three-box or separated trunk body |
| Estate / wagon | Road; four+ wheels | Any road powertrain | Extended roof and passenger-derived cargo volume |
| Coupe | Road; four+ wheels | Any road powertrain | Passenger car emphasizing fixed-roof two-door/sport form; market term varies |
| Convertible / roadster | Road; four+ wheels | Any road powertrain | Retractable/removable roof changes body configuration |
| SUV / crossover | Road/off-road; four+ wheels | Any road powertrain | Elevated multi-purpose body; construction and regulatory meanings vary |
| MPV / minivan | Road; four+ wheels | Any road powertrain | Passenger-volume and flexible seating priority |
| Limousine | Road; four+ wheels | Any road powertrain | Extended passenger accommodation and chauffeur/service use |
| Sports / super / hyper car | Road/track; four+ wheels | High-performance road powertrain | Performance-focused commercial/cultural recipe, not regulatory proof |
| Race car | Closed circuit/special course | Combustion/electric/hybrid traction | Competition rule class, safety cell and setup dominate configuration |
| Pickup | Road/off-road; four+ wheels | Any road powertrain | Passenger cab plus open cargo bed |
| Panel / cargo van | Road; four+ wheels | Any road powertrain | Enclosed cargo body integrated with cab/chassis |
| Minibus | Road; four+ wheels | Any road powertrain | Small passenger-service vehicle with multiple rows |
| City / transit bus | Road; multiple axles | Diesel/electric/hybrid/trolley | High-cycle passenger boarding and standing capacity |
| Coach | Road; multiple axles | Any road powertrain | Long-distance seated passenger service and luggage |
| School bus | Road; multiple axles | Any road powertrain | Student transport equipment, visibility and jurisdictional rules |
| Trolleybus | Road; rubber tires | External overhead electricity → motors | Road steering with continuous external electrical feed |
| Rigid truck / lorry | Road; multi-axle | Any road powertrain | Cargo body and cab share one chassis |
| Road tractor / prime mover | Road; multi-axle | Any road powertrain | Designed primarily to pull semitrailer through fifth wheel |
| Articulated truck | Road; tractor + semitrailer | Prime-mover traction | Temporary articulated commercial assembly |
| Road train | Road; prime mover + multiple trailers | Prime-mover traction | Multi-unit coupled formation with jurisdiction-specific limits |
| Flatbed / platform truck | Road | Truck traction | Open load deck and restraint system |
| Box / refrigerated truck | Road | Truck traction plus optional refrigeration | Enclosed or temperature-controlled cargo action system |
| Tanker truck | Road | Truck traction | Bulk liquid/gas containment, pumping and hazardous-load context |
| Dump / tipper truck | Road/off-road | Truck traction plus hydraulic action | Tilting body actively unloads bulk material |
| Concrete mixer truck | Road/site | Truck traction plus rotating mixer | Mobile material-processing payload |
| Refuse / recycling truck | Road | Truck traction plus compaction/lift | Collection, lifting and compaction utility system |
| Vehicle transporter | Road | Truck traction | Carries other vehicles with ramps/decks/restraints |
| Tow / recovery truck | Road | Truck traction plus boom/winch/lift | Recovers and transports disabled assets |
| Fire appliance | Road/site | Truck traction plus pump/aerial/rescue tools | Emergency mission systems define utility configuration |
| Ambulance | Road | Van/truck/car traction | Medical treatment and patient transport payload |
| Police / response vehicle | Road/off-road | Any road powertrain | Emergency signaling, communications and mission equipment |
| Mobile workshop / laboratory | Road/site | Truck/van traction | Workplace, tools, power and testing capability carried onboard |
| Motorhome / recreational vehicle | Road | Self-propelled road powertrain | Mobile habitation and life-support amenities |
| Armored road vehicle | Road/off-road | Any road powertrain | Protection, mass and regulated security mission specialization |

### 12.3 Off-road, agriculture, construction, mining, and material handling

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| ATV | Off-road; three/four low-pressure tires | Combustion/electric wheel traction | Straddle-seat compact all-terrain platform |
| UTV / side-by-side | Off-road; four+ wheels | Combustion/electric traction | Side-by-side occupants, roll protection and utility bed |
| Dune buggy / sand rail | Sand/off-road; wheels | Combustion/electric traction | Light open chassis optimized for loose terrain |
| Tracked carrier | Off-road/snow; tracks | Combustion/electric/hydraulic tracks | Continuous traction and low ground pressure |
| Half-track | Off-road; wheels + tracks | Driven wheels/tracks | Mixed rolling and continuous support architecture |
| Snow groomer | Snow; tracks | Engine/hybrid track drive | Blade/tiller action prepares snow surface |
| Wheeled agricultural tractor | Field/road; wheels | Combustion/electric traction + PTO/hydraulics | Prime mover for implements through hitch/PTO |
| Tracked agricultural tractor | Field; tracks | Combustion/electric track drive | Low-ground-pressure prime mover with agricultural interfaces |
| Combine harvester | Field; wheels/tracks | Self-propelled | Cuts, threshes, separates and stores crop in one mobile machine |
| Forage harvester | Field; wheels/tracks | Self-propelled | Cuts and processes forage, transfers to another vehicle |
| Self-propelled sprayer | Field; high-clearance wheels | Self-propelled plus pump/boom | Mobile precision application of liquids |
| Spreader | Field; wheels/tracks | Self-propelled or towed | Meters and distributes solid/liquid material |
| Mower / swather | Field/grounds | Self-propelled or tractor-driven | Cuts vegetation with deck, reel or header |
| Forestry harvester | Forest; wheels/tracks/legs | Self-propelled plus boom/head | Fells, delimbs and cuts trees |
| Forwarder / skidder | Forest; wheels/tracks | Self-propelled | Carries or drags harvested timber |
| Bulldozer | Earth; tracks/wheels | Self-propelled traction | Front blade pushes and grades material |
| Wheel loader | Site/mine; articulated wheels | Self-propelled hydraulic | Front linkage and bucket load material |
| Track loader / crawler loader | Site; tracks | Self-propelled hydraulic | Tracked support plus loader action |
| Skid-steer loader | Site; wheels/tracks | Differential/skid traction | Compact zero-radius steering with attachment interface |
| Backhoe loader | Site/road; wheels | Self-propelled hydraulic | Front loader plus rear excavator in one machine |
| Hydraulic excavator | Site; tracks/wheels | Self-propelled plus rotating upper works | Boom-arm-bucket excavation with slewing body |
| Walking excavator | Steep/wet terrain; articulated legs/wheels | Hydraulic limb repositioning | Adjustable limbs support and move on extreme terrain |
| Amphibious excavator | Wetland/water; pontoons/tracks | Track/hydraulic | Buoyant undercarriage enables shallow-water earthwork |
| Trencher | Ground; wheels/tracks | Self-propelled tool chain/wheel | Continuously cuts narrow trench |
| Motor grader | Roadworks; wheels | Self-propelled articulated | Mid-mounted blade creates precise surface profile |
| Scraper | Earth; wheels | Self-propelled or pushed/towed | Cuts, loads, carries and spreads soil |
| Compactor / road roller | Prepared/earth surface; drums/tires | Self-propelled | Applies static/vibratory compaction |
| Paver | Roadworks; tracks/wheels | Self-propelled | Places and screeds asphalt/concrete material |
| Off-highway haul truck | Mine/quarry; huge wheels | Diesel-electric/combustion/electric | High-capacity site haul with off-road envelope |
| Mobile drilling rig | Site/mine; truck/tracks | Self-propelled or carrier-mounted | Drill mast and rotary/percussive action dominate mission |
| Underground loader / LHD | Mine/tunnel; low-profile wheels | Diesel/electric | Confined-space load-haul-dump specialization |
| Mobile crane | Road/site; wheeled carrier | Self-propelled plus hoist/boom | Road mobility plus lifting configuration/outriggers |
| Crawler crane | Site; tracks | Track drive plus lattice/telescopic boom | High-capacity lifting on crawler base |
| Telehandler | Site/agriculture; wheels | Self-propelled | Telescopic boom accepts forks, bucket or platform |
| Forklift | Floor/yard; wheels | Electric/combustion traction | Mast/forks lift palletized loads |
| Reach truck / order picker | Warehouse; wheels/guide | Battery-electric | Narrow-aisle lifting and operator/pick specialization |
| Straddle carrier | Port/yard; tall wheeled frame | Self-propelled | Straddles and lifts containers beneath chassis |
| Container handler / reach stacker | Port/yard; wheels | Self-propelled | Telescopic spreader stacks containers |
| AGV | Indoor/site guideway | Electric | Follows fixed markers/routes under infrastructure control |
| AMR | Indoor/site free-ranging | Electric | Local perception and planning inside bounded environment |
| Mobile cleaner | Indoor/outdoor floor | Electric | Drive base integrated with sweep/scrub/vacuum action |

### 12.4 Rail, guideway, cable, vertical, and amusement conveyance

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Steam locomotive | Rail; flanged wheels | Fuel/heat → steam engine → driven wheels | Locomotive whose prime converter is steam |
| Diesel locomotive | Rail | Diesel engine → mechanical/hydraulic/electric traction | Onboard liquid-fuel prime mover |
| Electric locomotive | Rail | Overhead/third rail/battery → traction motors | Externally supplied or stored electric traction |
| Battery / fuel-cell locomotive | Rail | Stored electrochemical energy → motors | Non-continuous external feed; onboard zero-tailpipe option |
| EMU | Rail | Distributed electric traction | Passenger multiple unit with motors distributed across consist |
| DMU | Rail | Distributed diesel traction | Passenger multiple unit with onboard engines |
| Bi-mode multiple unit | Rail | External electric plus onboard source | Switches power path by route/operation |
| Passenger coach | Rail | Externally hauled | Passive passenger conveyance in consist |
| Sleeper / dining / service car | Rail | Externally hauled | Passenger coach specialized by onboard service/habitation |
| Freight box wagon | Rail | Externally hauled | Enclosed goods conveyance |
| Tank wagon | Rail | Externally hauled | Bulk liquid/gas containment |
| Hopper wagon | Rail | Externally hauled | Gravity-discharge bulk material body |
| Flat / well / intermodal wagon | Rail | Externally hauled | Platform or recessed deck for containers/vehicles |
| Autorack | Rail | Externally hauled | Multi-level vehicle carrier |
| Caboose / guard vehicle | Rail | Externally hauled | Crew, observation or braking role in historical/special consists |
| Tram / streetcar | Embedded/light rail | Electric traction | Operates in street/mixed environment on rails |
| Light-rail vehicle | Urban rail | Electric traction | Medium-capacity articulated urban passenger unit |
| Metro / subway train | Grade-separated rail | Electric distributed traction | High-frequency urban operation in controlled guideway |
| Monorail | Single-beam guideway | Electric traction | Straddles or suspends from one guide beam |
| Maglev | Magnetic guideway | Linear motor + magnetic support/guidance | Field support/propulsion replaces wheel-rail contact |
| Rack railway vehicle | Steep rail; rack | Pinion engages rack | Positive rack traction on steep grade |
| Funicular | Inclined rail | External cable haul | Counterbalanced/cable-driven vehicles constrained to slope |
| Cable car | Rail/road guide | Continuous or detachable cable grip | Vehicle traction supplied by moving cable |
| Aerial gondola / chairlift | Suspended cable | Cable haul | Cabin/chair supported and moved by ropeway |
| Aerial tramway | Suspended cable | Haul rope between terminals | Large cabin shuttles on fixed track ropes |
| Automated people mover | Dedicated guideway | Electric/infrastructure controlled | Small automated passenger units in bounded network |
| Guideway pod / PRT | Dedicated guideway | Electric automated | Small on-demand vehicle routed through guide network |
| Rail inspection vehicle | Rail | Self-propelled or hauled | Measurement/inspection payload is primary utility |
| Tamping / ballast machine | Rail | Self-propelled | Maintains track geometry and ballast |
| Rail grinder | Rail | Self-propelled | Grinding system restores rail profile |
| Rail crane / recovery unit | Rail | Self-propelled/hauled | Lifting and recovery action on rail base |
| Hi-rail vehicle | Road wheels + deployable rail gear | Road traction; rail guidance | Transitions between road and rail support |
| Mine cart | Mine rail | Hauled, gravity or powered | Confined industrial rail conveyance |
| Elevator / lift car | Vertical guide rails/cables | Cable, hydraulic or linear motor | Conveyance constrained to vertical shaft/guideway |
| Inclined lift | Inclined guideway | Cable/rack/hydraulic | Passenger/cargo car constrained to slope |
| Roller-coaster train | Amusement rail/track | Chain/launch/gravity | Track-constrained entertainment vehicle with gravity phases |

### 12.5 Surface-water, cushion, foiling, and marine work vehicles

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Canoe | Surface water; displacement hull | Paddle, pole, sail or small motor | Open narrow human-scale hull |
| Kayak | Surface water; displacement hull | Double-bladed paddle or small motor | Decked/open cockpit paddling craft |
| Rowing shell / scull | Surface water; slender hull | Oars through outriggers | Human power with backward-facing rowing geometry |
| Raft | Surface water; buoyant platform/tubes | Paddle, oar, motor, current or tow | Flexible/rigid buoyant platform without conventional hull form |
| Coracle / skin boat | Surface water; displacement | Paddle | Small traditional rounded lightweight hull |
| Punt / pole boat | Shallow water; flat hull | Pole against bottom | Propulsion reacts against bed rather than fluid |
| Gondola | Canal; displacement hull | Single oar | Asymmetric hull and standing rowing technique |
| Pedal boat | Surface water; hull/pontoons | Human pedals → paddlewheel/propeller | Cycle-like human input drives water propulsor |
| Stand-up paddleboard | Surface water; board buoyancy | Hand paddle | Standing rider on board-shaped hull |
| Windsurfer | Surface water; board | Wind → articulated sail | Rider directly controls free sail rig |
| Kiteboard | Surface water; board hydro support | Wind → tethered kite | Remote aerodynamic kite pulls rider/board |
| Sailing dinghy | Surface water; small hull | Wind → sail | Small open sailcraft, often planing |
| Keelboat / sailing yacht | Surface water; displacement/planing hull | Wind → sails; auxiliary motor optional | Ballasted keel and sailing rig |
| Catamaran | Surface water; two hulls | Sail, propeller, waterjet or hybrid | Twin-hull support architecture |
| Trimaran | Surface water; three hulls | Sail, propeller or hybrid | Main hull plus two outriggers |
| Proa / outrigger canoe | Surface water; asymmetric multi-hull | Sail/paddle/motor | Main hull plus outrigger or asymmetric shunting architecture |
| Displacement motorboat | Surface water; hull buoyancy | Engine/motor → water propeller | Operates primarily in displacement regime |
| Planing boat / speedboat | Surface water; planing hull | Engine/motor → water propeller/jet | Dynamic lift raises hull at speed |
| Personal watercraft | Surface water; compact planing hull | Engine/motor → waterjet | Rider sits/stands astride compact jet-driven craft |
| Airboat | Surface water; displacement/planing hull | Engine/motor → air propeller/fan | Hull supported by water; thrust reacts against air |
| Submerged-propeller boat | Surface water; hull | Shaft/pod/outboard → submerged propeller | Propeller works below surface against water |
| Surface-piercing propeller craft | Surface water; planing hull | Partially immersed propeller | Propeller disk crosses air-water interface at speed |
| Waterjet boat | Surface water; hull | Pump/impeller → jet nozzle | Water is ingested and expelled through internal duct |
| Pump-jet craft | Surface/submerged; hull | Ducted rotor/stator pump-jet | Shrouded water propulsor controls wake/noise/efficiency |
| Paddlewheel vessel | Surface water; hull | Engine/human → paddlewheel | Radial paddles cyclically react against water |
| Cycloidal / Voith-Schneider vessel | Surface water; hull | Vertical-axis cycloidal propulsor | Thrust direction changes rapidly without conventional rudder |
| Hydrofoil craft | Surface water; hull + foils | Any marine/air propulsor | Hydrodynamic foils support hull clear of water at speed |
| Hovercraft | Land/water surface; air cushion | Lift fan + air thrust fan/propeller | Pressure cushion supports across multiple surfaces |
| Wing-in-ground craft | Near water/ground; aerodynamic lift | Air propeller/jet | Flies primarily in surface-effect envelope |
| Ferry | Waterway; hull | Any marine propulsion | Scheduled transport of passengers, vehicles and/or rail units |
| Ro-ro ship | Sea; displacement hull | Marine propulsion | Roll-on/roll-off decks and ramps for wheeled cargo |
| Passenger / cruise ship | Sea/inland; displacement hull | Marine propulsion | Large passenger accommodation/hospitality systems |
| Container ship | Sea; displacement hull | Marine propulsion | Cellular container cargo architecture |
| Bulk carrier | Sea; displacement hull | Marine propulsion | Large holds for unpackaged dry bulk |
| Tanker / gas carrier | Sea; displacement hull | Marine propulsion | Bulk liquid/gas containment and cargo handling |
| Tug | Harbor/sea; displacement hull | High-thrust propeller/azimuth drive | Tow/push capability and bollard pull dominate design |
| Pushboat | Inland water; hull | High-thrust marine propulsion | Pushes barge formations through rigid contact |
| Barge / lighter | Water; displacement hull | Usually towed/pushed; sometimes self-propelled | Cargo platform may be passive or minimally powered |
| Fishing vessel | Sea/inland; hull | Marine propulsion | Gear deployment, catch handling and storage define mission |
| Dredger | Water; hull/platform | Self-propelled/towed plus dredge plant | Excavates/pumps seabed or river material |
| Research / survey vessel | Water; hull | Marine propulsion | Scientific, mapping, sampling and instrument support |
| Uncrewed surface vessel | Water; hull | Sail/electric/combustion/solar | No required onboard crew; remote/autonomous control per function |
| Lifeboat / rescue boat | Water; hull | Marine propulsion or oar/sail | Emergency survival/rescue, launch and recovery capability |
| Fireboat | Water; hull | Marine propulsion plus high-capacity pumps | Waterborne firefighting action system |
| Landing craft | Shore/water; hull | Marine propulsion | Beach access and ramp for troops/vehicles/cargo |
| Icebreaker | Ice-covered water; strengthened hull | High-power marine propulsion | Hull/propulsion designed to break and navigate ice |
| Houseboat | Inland/coastal water; hull | Self-propelled or towed | Habitation is primary utility |
| Floating crane / installation vessel | Water; barge/ship | Self-propelled/towed plus crane | Heavy lift or offshore installation dominates mission |
| Semi-submersible mobile platform | Offshore; buoyant columns/pontoons | Towed or dynamically positioned | Ballasted operating draft and offshore work function |

### 12.6 Submerged, seabed, tethered, drifting, and underwater vehicles

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Crewed submarine | Submerged; buoyant pressure hull | Nuclear/diesel-electric/battery propeller/pump-jet | Sustained submerged navigation with crew and life support |
| Midget submarine | Submerged; compact pressure hull | Electric/other marine propulsion | Small crewed/mission-specific submerged craft |
| Tourist submersible | Submerged; pressure vessel | Electric thrusters | Passenger viewing, depth and support-vessel envelope |
| Research submersible | Submerged; pressure vessel | Electric thrusters | Crewed scientific observation/sampling capability |
| Rescue submersible | Submerged; pressure vessel | Electric thrusters | Docking and survivor transfer from disabled submarine |
| Work-class ROV | Submerged; tethered | Electric/hydraulic thrusters; topside power/control | Tethered remote vehicle with manipulators and heavy work payload |
| Inspection-class ROV | Submerged; tethered | Electric thrusters | Compact visual/sensor inspection with tether |
| AUV | Submerged; free-swimming | Battery/fuel-cell propeller/thruster | Uncrewed independent mission execution without continuous tether |
| Underwater glider | Submerged/surface cycling | Variable buoyancy + wings | Buoyancy changes produce slow forward gliding |
| Diver propulsion vehicle | Submerged; diver-held/ridden | Battery-electric propeller | Assists a human diver; diver remains operator/principal |
| Swimmer delivery vehicle | Submerged; crew/passenger platform | Electric propeller | Carries divers while often exposed to water |
| Benthic crawler | Seabed; tracks/wheels/legs | Electric/hydraulic traction | Moves in contact with seabed rather than free swimming |
| Seabed trencher / plough | Seabed; skids/tracks | Towed or self-propelled plus tool | Burial/excavation of cable or pipe |
| Pipe/tunnel underwater crawler | Flooded pipe/tunnel contact | Wheels/tracks/traction | Confined submerged inspection/maintenance |
| Towed underwater body | Submerged; tow cable | External tow | Sensor/sonar body trajectory supplied by surface/air vehicle |
| Profiling float | Water column | Buoyancy modulation and drift | Ambient current plus depth cycling; limited horizontal control |
| Drifter buoy | Surface/subsurface drift | Current/wind; no active propulsion | Observational vehicle whose movement is environmental |
| Diving bell | Submerged; cable suspended | External hoist | Crewed chamber lowered/raised from support system |
| Regulated torpedo / UUV | Submerged; free-swimming | Propeller/pump-jet/other | Self-propelled regulated payload vehicle; strict authority and safety pack |

### 12.7 Heavier-than-air, rotorcraft, powered-lift, and personal flight

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Sailplane / glider | Air; aerodynamic wing lift | Tow/launch + gravity/thermal energy | Sustained unpowered flight after external launch |
| Hang glider | Air; flexible/rigid wing | Gravity/air currents; foot launch | Pilot suspended beneath wing and weight-shift/control surfaces |
| Paraglider | Air; inflated parafoil | Gravity/air currents; foot launch | Flexible ram-air wing without rigid airframe |
| Paramotor / powered paraglider | Air; parafoil | Back-mounted/cart air propeller | Paraglider lift with compact powered thrust unit |
| Parachute | Air; drag/parafoil | Gravity; steering optional | Controlled descent/recovery rather than sustained powered flight |
| Ultralight / microlight | Air; fixed/flex wing | Small engine/electric propeller | Very light recreational aircraft under jurisdiction-specific rules |
| Single-engine airplane | Air; fixed wing | One piston/turboprop/electric propulsor | Conventional fixed-wing flight with one primary power unit |
| Multi-engine airplane | Air; fixed wing | Two+ propeller/jet power units | Multiple primary propulsors and engine-out envelope |
| Airliner | Air; fixed wing | Turbofan/turboprop/other | Certified high-capacity passenger transport |
| Cargo airplane | Air; fixed wing | Any aviation powertrain | Freight doors/floor/restraint and payload mission |
| Business jet | Air; fixed wing | Jet propulsion | Executive passenger configuration and performance |
| Floatplane / seaplane | Water + air; floats/wings | Air propeller/jet | Takes off/lands on water using floats |
| Flying boat | Water + air; hull/wings | Air propeller/jet | Fuselage/hull provides water buoyancy |
| Amphibious airplane | Ground/water/air | Air propeller/jet | Landing gear plus water-support configuration |
| STOL / bush plane | Air + short/unprepared surface | Propeller/jet | Short-field and rough-site operating envelope |
| Aerobatic airplane | Air; fixed wing | High power-to-weight propulsion | Maneuver envelope and control authority optimized for aerobatics |
| Agricultural airplane | Air; fixed wing | Propeller | Low-altitude spray/spread payload and agricultural mission |
| Firefighting airplane | Air; fixed wing | Propeller/jet | Carries/releases suppressant under specialized low-level operation |
| Uncrewed fixed-wing aircraft | Air; fixed wing | Electric/combustion/solar | Remote/autonomous operation without onboard crew |
| Single-main-rotor helicopter | Air; rotor lift | Engine/motor → main rotor; anti-torque system | Rotor provides lift/thrust; tail rotor/other handles torque |
| Coaxial helicopter | Air; coaxial rotors | Counter-rotating rotors | Concentric rotors cancel torque |
| Tandem-rotor helicopter | Air; fore/aft rotors | Two main rotors | Longitudinally separated lifting rotors |
| Intermeshing-rotor helicopter | Air; intermeshing rotors | Synchropter transmission | Overlapping angled rotors intermesh without collision |
| Autogyro / gyroplane | Air; autorotating rotor | Separate propeller supplies thrust | Rotor is not engine-driven for sustained lift |
| Multirotor | Air; multiple rotors | Electric/combustion rotor thrust | Differential rotor thrust controls attitude and translation |
| Ducted-fan aircraft | Air; ducted propulsors | Fans inside shrouds/ducts | Duct changes safety, pressure and efficiency characteristics |
| Compound helicopter | Air; rotor + wing/propulsor | Rotor lift plus separate forward thrust/wing | Combines rotorcraft and airplane paths |
| Tiltrotor | Air; rotating nacelle/rotors | Rotors vector between lift and cruise | Propulsor orientation transitions helicopter-to-airplane mode |
| Tiltwing | Air; rotating wing + propulsors | Wing/propulsors tilt together | Whole lifting wing changes orientation for transition |
| Lift-plus-cruise eVTOL | Air; separate lift/cruise propulsors | Electric lift rotors + cruise propulsor | Distinct vertical-lift and forward-flight paths |
| Vectored-thrust eVTOL | Air; wing/body + vectoring propulsors | Electric propulsors redirect thrust | Same propulsion set supplies lift and cruise through vectoring |
| Tailsitter | Air; wing/rotors | Propeller/rotor | Whole aircraft changes attitude between vertical and horizontal flight |
| Powered-lift aircraft | Air; powered lift + wing | Jet/rotor/fan vectoring | Powered lift during low speed with airplane-like cruise |
| Ornithopter | Air; flapping wings | Muscle/engine/motor → wing flapping | Oscillating wings create lift and/or thrust |
| Cyclocopter | Air; cycloidal rotors | Cyclorotor | Rotating spanwise blades vector thrust cyclically |
| Personal jet suit / jetpack | Air; body-worn | Jet/ducted fan/rocket thrust | Wearable powered flight; human remains operator, not component |
| Kite / tethered wing | Air; aerodynamic lift | Wind; tether reaction | Tethered ambient-powered airborne system |
| Rocketplane / spaceplane in atmospheric mode | Air/space; wing/body lift | Rocket/jet/combined cycle | Transitions between atmospheric flight and space trajectory |

### 12.8 Balloons, aerostats, blimps, and airships

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Hot-air balloon | Air; heated-air aerostatic lift | Wind drift; burner controls altitude | Open balloon without powered horizontal thrust by default |
| Gas balloon | Air; helium/hydrogen lift | Wind drift; ballast/vent altitude control | Lifting gas at ambient temperature |
| Tethered balloon | Air; aerostatic lift + tether | Wind; tether/winch controls position | Physical tether constrains movement and may carry power/data |
| Aerostat | Air; tethered shaped envelope | Wind-aligned; winch | Persistent sensor/communications platform anchored to ground/ship |
| Stratospheric balloon | High atmosphere; aerostatic | Drift plus altitude modulation | Long-duration high-altitude operating envelope |
| Non-rigid airship / blimp | Air; envelope aerostatic lift | Engine/motor → air propellers | Envelope pressure maintains shape; no rigid framework |
| Semi-rigid airship | Air; aerostatic lift | Air propellers | Keel/frame carries some structural loads |
| Rigid airship | Air; rigid hull + gas cells | Air propellers | Rigid structure maintains outer shape independent of gas pressure |
| Hybrid airship | Air; aerostatic + aerodynamic/propulsive lift | Air propellers/rotors | Combines buoyancy with dynamic lift or vectored thrust |
| Thermal airship | Air; heated-air elongated envelope | Air propellers optional | Airship form using thermal lift |
| Powered balloon | Air; balloon envelope | Compact fan/propeller | Balloon gains limited horizontal propulsion without full airship architecture |
| Variable-buoyancy airship | Air; aerostatic | Buoyancy control plus propulsors | Actively changes buoyancy rather than only ballast/venting |
| Indoor microblimp | Indoor air; small envelope | Battery micropropellers | Model-scale low-speed aerostatic vehicle in indoor envelope |
| Vacuum airship concept | Air; evacuated structure | Propulsors optional | Theoretical/experimental aerostatic recipe supported without asserting feasibility |

### 12.9 Rockets, launch systems, spacecraft, and planetary mobility

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Model rocket | Atmosphere/suborbital; ballistic | Solid/liquid/hybrid/cold-gas rocket | Model-scale launch article with recovery and range-safety context |
| Sounding rocket | Suborbital | Rocket stages | Carries experiment through suborbital trajectory |
| Suborbital passenger/research vehicle | Atmosphere/space | Rocket/spaceplane | Returns after non-orbital spaceflight |
| Orbital launch vehicle | Ground/air launch → orbit | Multi-stage rocket | Delivers payload to orbit through staged propulsion |
| Reusable booster | Launch/reentry/landing | Rocket; recovery propulsion/aero | Primary stage designed for controlled recovery and reuse |
| Expendable stage | Launch trajectory | Rocket | Stage intended to be consumed/discarded after burn |
| Strap-on booster | Launch stack | Solid/liquid rocket | Attached auxiliary stage separates from core |
| Upper stage | Near-space/orbit | Rocket | Performs orbital insertion or transfer after lower-stage separation |
| Kick stage | Orbit | Compact rocket/electric propulsion | Final payload deployment/transfer stage |
| Spaceplane | Atmosphere + space | Rocket/combined cycle + aerodynamic surfaces | Winged or lifting-body reusable orbital/suborbital vehicle |
| Reentry capsule | Space → atmosphere → surface | Ballistic/lifting reentry; parachute/propulsive recovery | Pressure vessel and thermal protection for return |
| Crew spacecraft | Space/orbit | Chemical/electric thrusters | Life support, crew control, rendezvous/docking and return |
| Cargo spacecraft | Space/orbit | Chemical/electric thrusters | Uncrewed logistics, delivery and disposal/return |
| CubeSat / small satellite | Orbit | Launch-deployed; optional micropropulsion | Standardized small form factor or small spacecraft mission |
| Large satellite / spacecraft bus | Orbit/deep space | Reaction control/electric/chemical | Bus hosts payload, power, attitude and communications |
| Space station / module | Orbit | Station keeping; externally assembled | Long-duration habitation/research infrastructure that remains a mobile orbital asset |
| Free-flyer | Orbit | Microthrusters/reaction control | Independent nearby spacecraft for inspection/research |
| Orbital tug | Orbit | Electric/chemical propulsion | Moves, deploys or disposes other spacecraft |
| Servicing vehicle | Orbit | Rendezvous propulsion + manipulators | Inspects, repairs, refuels or upgrades another spacecraft |
| Space tanker / depot | Orbit | Station keeping | Stores and transfers propellant/energy to other vehicles |
| Lander | Planetary/moon surface transition | Descent propulsion/airbag/aero/parachute | Transitions from flight/orbit to surface |
| Ascent vehicle | Planetary/moon surface → flight/orbit | Rocket | Launches from non-Earth surface |
| Planetary rover | Planetary surface; wheels/tracks/legs | Electric/nuclear-powered traction | Surface mobility under remote/autonomous control and delay |
| Planetary hopper | Planetary surface/ballistic | Rocket/spring/buoyancy | Moves between sites by repeated hops |
| Planetary hauler / crew rover | Planetary surface | Electric/nuclear traction | Carries crew/cargo with surface operations support |
| Orbiter / flyby probe | Planetary/deep space | Chemical/electric/gravity assist | Scientific trajectory around or past target |
| Sample-return vehicle | Surface/orbit/reentry chain | Multiple stages/capsule | Collects and returns physical samples through staged assembly |
| Solar-sail spacecraft | Space | Radiation pressure on sail | Propellantless thrust from photons |
| Tether spacecraft | Orbit/space | Electrodynamic/momentum-exchange tether | Long tether exchanges momentum/energy with field or another mass |
| Reentry body / return canister | Space → atmosphere | Ballistic/lifting descent | Compact payload protection and recovery vehicle |
| Escape / abort vehicle | Launch/atmosphere | Rocket or separation system | Separates crew/capsule from failing launch stack |
| Deployable subsatellite | Host-carried → orbit free-flight | Spring release; optional propulsion | Independent asset deployed from parent spacecraft |

### 12.10 Mobile robots, unusual locomotion, and confined-domain machines

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Differential-drive robot | Ground; two driven wheels/casters | Electric wheel traction | Heading controlled by left/right speed difference |
| Ackermann robot | Ground; four+ wheels | Electric/combustion traction | Steered wheel geometry approximates road vehicle kinematics |
| Skid-steer robot | Ground; wheels/tracks | Differential traction | Turns through slip between sides |
| Omnidirectional / mecanum robot | Floor; angled rollers/wheels | Independent wheel drives | Can translate laterally without changing heading |
| Spherical robot | Ground; rolling shell/ball | Internal mass/actuator | Whole body rolls as locomotion interface |
| Tracked robot | Ground; tracks | Electric/hydraulic track drive | Continuous contact and obstacle negotiation |
| Biped robot | Ground; two legs | Joint actuators | Alternating legged gait and dynamic balance |
| Quadruped robot | Ground; four legs | Joint actuators | Four-legged gait over terrain |
| Hexapod / multi-leg robot | Ground; six+ legs | Joint actuators | Static-stability gait and high contact redundancy |
| Humanoid mobile robot | Ground; legs/wheels + torso/arms | Joint/wheel actuators | Human-like morphology combines mobility and manipulation |
| Hopping robot | Ground/low gravity | Spring/actuator/rocket impulse | Discrete ballistic hops rather than continuous gait |
| Snake / continuum robot | Surface/confined space | Segment/continuum actuation | Undulating or shape-changing body provides locomotion |
| Inchworm robot | Surface/pipe | Alternating anchors + extension | Sequential grip and body extension |
| Wall / ceiling crawler | Wall/ceiling | Wheels/tracks/legs plus adhesion | Suction, magnetic, electrostatic or adhesive support |
| Magnetic inspection crawler | Ferromagnetic surface | Magnetic wheels/tracks | Magnetic support enables vertical/inverted movement |
| Cable-climbing robot | Cable/rope | Rollers/grippers | Locomotion constrained to cable infrastructure |
| Pipe / sewer crawler | Pipe/duct | Wheels/tracks/inchworm | Diameter/bends/flow define confined operating domain |
| Borehole sonde / logging tool | Borehole; cable/fluid | Winch, tractor or flow | Instrument vehicle moves through narrow deep bore |
| Burrowing / mole robot | Soil/rock | Auger, peristaltic body, drill | Creates or follows subsurface path through material |
| Soft robot | Surface/fluid/confined | Pneumatic/hydraulic/material actuation | Compliant body deformation is central mechanism |
| Modular self-reconfiguring robot | Multiple domains | Module actuators | Topology changes by coupling/decoupling modules |
| Swarm robot | Any domain | Local mobility per member | Collective capability emerges from effective-dated membership/coordination |
| Sidewalk delivery robot | Pedestrian ground | Battery wheels/legs | Small autonomous cargo service around people |
| Warehouse AMR | Indoor floor | Battery wheels | Free-ranging logistics under site/fleet orchestration |
| Telepresence robot | Indoor ground | Electric wheels | Remote human presence via camera/display/audio |
| Mobile manipulator | Ground base + arm | Any base plus manipulator | Mobility and end-effector work are co-primary |
| Agricultural field robot | Field | Wheels/tracks/legs | Cultivation, scouting, weeding or harvest task in crop environment |
| Firefighting / disaster robot | Hazardous terrain | Tracks/wheels/legs | Remote/autonomous operation with suppression, sensing or rescue tools |
| EOD / bomb-disposal robot | Ground | Tracks/wheels | Remote manipulation in hazardous regulated mission |
| Robot mower | Ground/grass | Battery wheel traction + blade | Bounded autonomous grounds maintenance |
| Robot vacuum / floor cleaner | Indoor floor | Battery wheel traction + cleaning | Small domestic/service mobile action platform |
| Battlebot / competition robot | Arena | Wheels/tracks/legs + regulated action tool | Competition rules, safety interlocks and arena operation |
| Mobile animatronic performer | Stage/site | Wheels/legs/hidden carrier | Character performance, synchronized media and public interaction |
| Medical capsule / microrobot | Inside-body/medical domain | Peristalsis, magnetic field, micropropulsion | Clinical device under strict human-rights, medical and containment boundaries |

### 12.11 Passive, externally moved, towed, pushed, carried, and ambient-driven vehicles

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Drawbar trailer | Road/site; wheels | Towed through drawbar | Own axles support load; towing connection transmits force/control |
| Semitrailer | Road; wheels + tractor fifth wheel | Towed | Part of load supported by tractor through fifth wheel |
| Full trailer | Road; front/rear axles | Towed | Carries own load vertically; steerable drawbar assembly |
| Dolly | Road/site; wheels | Towed | Converts or supports coupling between vehicle/trailer units |
| Caravan / travel trailer | Road; wheels | Towed | Passive road conveyance with habitation |
| Bicycle trailer | Ground; one/two wheels | Towed by cycle | Light cargo/child/pet conveyance coupled to bicycle |
| Boat / aircraft transporter trailer | Road/site; wheels | Towed | Cradle/restraint specialized to carry another vehicle |
| Towed agricultural implement | Field; wheels/skids | Tractor tow/PTO/hydraulics | Performs work while externally moved/powered |
| Unpowered wagon | Road/rail/field; wheels | Towed/pushed/gravity | Passive general conveyance |
| Sled / freight sledge | Snow/ice/ground; runners | Human/animal/vehicle tow | Sliding cargo conveyance |
| Unpowered railcar | Rail | Locomotive or gravity | Passive consist member with own role and history |
| Unpowered barge | Water; hull | Tug/pushboat/tow/current | Passive waterborne cargo platform |
| Towed glider | Air; wing | Aircraft/vehicle tow then glide | External launch transitions to gravity/aerodynamic flight |
| Parachute recovery system | Air; canopy | Gravity descent | Vehicle/person/payload descent and recovery assembly |
| Cargo pod | Host/carrier interface | Carried, towed or deployed | Modular conveyance payload with independent custody/identity |
| Intermodal container on chassis | Road/rail/ship assembly | Carried by vehicle | Container identity distinct from carrier and chassis |
| Towed sonar / sensor body | Submerged/air | Tow cable | Instrument trajectory supplied by another vehicle |
| Towed target / decoy | Air/water/ground | Tow cable | Regulated training/protection payload with own configuration |
| Aerial target drone | Air | Launched, towed or self-propelled | Regulated target mission; may transition from carrier |
| Drop probe / sonde | Air/water/space | Gravity, parachute, drift | Released sensor vehicle produces data while descending/drifting |
| Drifter / buoy | Water | Current/wind/wave | Ambient-driven observational asset |
| Counterweight conveyance | Guide/cable | Gravity and cable | Paired mass exchanges potential energy with vehicle |
| Human-carried palanquin | Ground; carried | Human carriers | Passenger conveyance entirely externally supported/moved |
| Animal-drawn wagon / plough | Ground | Animal pull | Animal actor provides force; vehicle/tool maintains separate identity |
| Carrier-mounted vehicle | Host support | Host carries until release | Asset remains a vehicle while stowed on mothership/transporter |

### 12.12 RC, model, scale, replica, prototype, and digital representations

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| RC touring / drift car | Model ground; wheels | Electric/nitro wheel traction | Scale road chassis configured for grip or controlled drift |
| RC buggy / truggy | Model off-road; wheels | Electric/nitro traction | Off-road suspension, tires and race class |
| RC crawler / scaler | Model terrain; wheels/tracks | Electric geared traction | Low-speed articulation/traction and scale appearance |
| RC drag / speed-run car | Model track | Electric/nitro traction | Straight-line acceleration/top-speed configuration |
| RC monster truck | Model terrain; large wheels | Electric/nitro traction | Oversized tires, suspension travel and stunt use |
| Tether car | Model circular track | Combustion/electric wheel traction | Physically tethered high-speed path without free steering |
| Slot car | Model guide slot | Track electricity → motor | Guide pin and slot constrain path |
| RC sailboat | Model water; hull | Wind → sails | Remote sail/rudder control; ambient propulsion |
| RC propeller boat / hydroplane | Model water | Electric/nitro → water propeller | Scale planing/hydroplane with submerged/surface propulsor |
| RC airboat | Model water | Electric/engine → air propeller | Model hull support with air-reacting thrust |
| RC submarine | Model submerged | Electric propeller + ballast/depth control | Remote underwater operation and pressure/sealing constraints |
| RC fixed-wing aircraft | Model air; wing | Electric/combustion propeller/jet | Remote pilot or autopilot; model scale and airspace rules |
| Free-flight model aircraft | Model air | Rubber/electric/combustion/glide | No active command after launch beyond onboard trim/control |
| Control-line aircraft | Model air; circular tether | Engine/electric propeller | Pilot commands through physical lines |
| RC helicopter | Model air; rotor | Electric/nitro/turbine rotor drive | Remote rotorcraft dynamics and control |
| RC multirotor / drone | Model air; rotors | Battery-electric rotors | Remote/assisted/autonomous model UAS |
| RC blimp | Model air; aerostatic | Battery micropropellers | Lift gas supports; remote propulsion/trim |
| Model train | Model rail | Track/battery power or passive | Scale rail vehicle/consist on model gauge |
| Model rocket | Model launch | Solid/liquid/hybrid rocket | Recoverable/consumable model flight article |
| RC construction/agriculture machine | Model ground | Electric/hydraulic | Functional scale work mechanisms and remote operation |
| Combat / competition robot | Model/arena | Electric mobility + action mechanism | Rule-governed competition machine with safety controls |
| Scale replica | Any model domain | Any corresponding mechanism | Physical asset linked by explicit represents/scale relationship |
| Functional prototype / test model | Any domain | Any | Validates selected geometry, dynamics, control or mission fidelity |
| Static display model | Stationary/display | None | Embodied replica but not admitted as a VehicleAsset unless designed for movement |
| Digital simulation twin | Digital | Simulated | DigitalTwin linked to asset/design; never conflated with physical vehicle |

### 12.13 Amphibious, multimodal, transforming, modular, and carrier-deployed vehicles

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Amphibious car | Road wheels + water hull | Wheel traction + water/air propulsor | Same asset transitions road-to-water with mode-specific graphs |
| Amphibious truck / carrier | Ground tracks/wheels + buoyancy | Ground traction + marine propulsor | Heavy cargo/troop/utility operation across shore transition |
| Amphibious ATV | Ground wheels/tracks + flotation | Wheel/paddle/propeller | Compact off-road vehicle capable of water crossing |
| Amphibious bus | Road wheels + hull | Wheel traction + marine propeller/jet | Passenger service across road and water |
| Seaplane / flying boat | Water + air | Water taxi plus air propeller/jet | Water support transitions to aerodynamic lift |
| Roadable aircraft | Road + air | Wheel traction and/or air propulsor | Transforms/folds between legal road and flight configurations |
| Flying car / passenger eVTOL | Ground/vertiport + air | Electric rotor/propulsor; optional road drive | Personal/air-taxi mission with vertical flight and possible road mode |
| Submersible boat | Surface + underwater | Marine propellers/thrusters | Transitions buoyancy, pressure and control state to dive |
| Boat-caravan / floating motorhome | Road/water | Towed/road traction plus marine propulsion | Habitation persists across transport domains |
| Hovercraft | Land/water/ice surface | Air cushion + air thrust | Same support principle spans several surfaces |
| Wing-in-ground craft | Water/ground-effect air | Air propeller/jet | Operates between marine and aircraft regimes near surface |
| Wheel-track convertible | Ground | Traction through selectable wheels/tracks | Support/drive interface changes by configuration |
| Wheel-leg robot | Ground | Wheels plus articulated legs | Rolls efficiently and steps/climbs when needed |
| Air-ground drone | Ground + air | Wheel traction + rotors | One asset drives and flies under different control envelopes |
| Air-water drone | Air + surface/submerged | Rotors/propellers/thrusters | Transitions across air-water boundary |
| Carrier-deployed microvehicle | Host-carried → independent domain | Host release + own propulsion | Configuration and authority change at deployment/recovery |
| Transforming modular rescue machine | Multiple domains | Swappable wheel/track/rotor/leg modules | Topology, geometry and capability change by module set |
| Rocket-launched glider / aircraft | Launch/space → air | Rocket phase then aerodynamic glide/propulsion | Distinct staged movement regimes in one mission |

```text
Catalog completeness test
If a new machine is absent from every row, onboarding still succeeds by recording its support path, propulsion/resource graph, steering/stopping/stability, control assignments, utility graph, operating envelope, configuration and evidence. A curator may later publish a new recipe without migrating the asset record.
```

# 13. Domain packs, external classifications, and interoperability

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.13 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:dfdfaab9805f823431c2f13fe3db355633aa54dd6d488197241dd17b0692bf93

A domain pack makes a community feel native without forking identity, event, evidence or configuration semantics. It adds specialized terms, schemas, forms, graphs, units, constraints, imports, exports, privacy rules and conformance fixtures. Cross-domain machines compose packs; they do not copy them.

| Pack contribution | Required behavior |
| --- | --- |
| Vocabulary | Namespaced stable concept IDs, definitions, labels, synonyms, broader/narrower links and deprecation mappings |
| Record schemas | Versioned payloads for domain events, observations, tests, documents and state intervals |
| Graph types | Specialized energy, support, propulsion, control, utility, interface and safety nodes/ports |
| Capabilities | Domain-specific capability definitions with envelope and evidence requirements |
| Validation | Structural, dimensional, graph, temporal, authority, privacy and domain constraints with severity |
| Experience | Native onboarding, fields, names, timelines, meters, reports, search facets and maintenance views |
| Mappings | Authority/registry, competition, insurer, manufacturer, supply and marketplace adapters |
| Migrations | Machine-readable projections between published versions; original record remains immutable |
| Fixtures | Golden example records and round-trip/conformance tests |
| Governance | Publisher, owners, version, compatibility, dependencies, signature, license and change notes |

### Pack rules

- Packs may extend but never redefine kernel meanings, weaken core evidence/privacy rules or repurpose a published identifier.

- Every term and schema is namespaced. Unknown terms and unavailable packs remain preservable and round-trippable.

- Dependencies resolve deterministically and lock per configuration. Conflicts fail explicitly; they never silently choose a winner.

- Manufacturer, organizer, regulator and tenant packs can remain private or shared while mapping to common concepts.

- Bridge packs describe valid combinations such as road+marine, air+space, RC+competition and mobile-base+industrial-tool.

- A pack can make rules stricter in its declared scope; it cannot invalidate unrelated historical records or other contexts.

### External classifications are adapter records

| External scheme | Useful distinction | RTracer treatment |
| --- | --- | --- |
| EU M/N/O | Passenger, goods and trailer road categories | Authority/jurisdiction/version classification over an exact asset/configuration |
| EU L-category | Powered cycles, mopeds, motorcycles, sidecars and quadricycles | Road regulatory mapping; not a universal physical hierarchy |
| EU T/C/R/S | Wheeled/tracked agricultural tractors, trailers and interchangeable towed equipment | Agricultural regulatory mapping plus coupling role |
| SAE J3016 | On-road driving-automation features and sustained driving task | Map engaged driving functions and operating domain; never assign globally |
| EASA Open/Specific/Certified | Risk category of a drone operation | Attach to operation, configuration, jurisdiction and authorization |
| FAA aircraft category/designator | Physical aircraft families plus performance/operational distinctions | Map source definitions while preserving physical facets |
| IMO ship/MASS sources | Treaty-specific ship concepts and function/mode-based autonomous operation | Preserve exact instrument and functional assignment |
| ERA vehicle type/register | Authorised rail type/variant/version and individual registration | Separate design authorization from individual asset identity and keeper |
| Competition class | Eligibility for an event/rule edition | Configuration- and date-specific class assertion with scrutineering evidence |
| Insurer/market class | Commercial risk, valuation or listing segment | Provider-specific projection; no claim about physical truth or legality |

```text
Why adapters matter
Official maritime sources explicitly warn that ship-type definitions differ by instrument. Drone risk categories depend on the operation. Rail registers separate authorized type from individual vehicle registration. These are not defects to flatten; they prove that authority, context and time belong in the classification record.
```

# 14. Kernel records, schema registry, validation, storage, and APIs

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.14 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:5abf9271ddffcc29824b2924d9f001ff09bd3783b5d54d0edcbff0aeebf70b5a

```text
Closed kernel, open registered semantics
Durable identity + typed append-only records + immutable configuration graphs + composable domain packs. The kernel stays small; vocabularies and payload schemas grow without data loss.
```

### 14.1 Small universal kernel

| Kernel object | Purpose |
| --- | --- |
| EntityRoot | Opaque durable identity and root kind |
| DesignDefinition | Controlled design, model, revision, variant and intended characteristics |
| IdentifierAssertion | VIN, serial, plate, MAC, transponder, registration, call sign and other sourced identifiers |
| FacetAssertion | Attributed, scoped and time-bounded classification fact |
| RelationshipAssertion | Typed role, custody, composition, control, coupling, rights or semantic relationship |
| TypedRecordEnvelope | Common immutable wrapper for every event, claim, observation, state, grant and receipt |
| EvidenceArtifact | Content-addressed photo, document, video, scan, signature or raw dataset |
| ConfigurationSnapshot | Immutable exact build and active graphs |
| CapabilityRealization | Function available under configuration and envelope |
| Operation / Mission | Bounded use with configuration, control regime, environment and outcome |
| AuthorityGrant | Scoped, revocable permission from a principal |
| ActionReceipt | Request, authority, execution and result for consequential action |
| VocabularyTerm | Stable namespaced semantic concept |
| SchemaDefinition | Immutable versioned payload or graph contract |
| DomainPackManifest | Signed package of vocabularies, schemas, constraints, mappings and fixtures |

### 14.2 Typed append-only record envelope

```text
Illustrative canonical record envelope
{
  "record_id": "rec_...",
  "record_type": "rtracer.modification.embodied/v2",
  "schema_ref": "schema:rtracer.modification.embodied:2.1.0",
  "subjects": [{"entity_ref": "asset_...", "role": "modified_asset"}],
  "valid_time": {"from": "2026-07-21T10:00:00Z", "to": "2026-07-21T13:00:00Z"},
  "recorded_at": "2026-07-21T13:08:12Z",
  "actor_ref": "party_...",
  "configuration_before": "cfg_...",
  "configuration_after": "cfg_...",
  "payload": {},
  "evidence_refs": ["evidence_..."],
  "authority_ref": "grant_...",
  "visibility_policy_ref": "policy_...",
  "integrity": {"digest": "...", "signature_ref": "..."},
  "supersedes": [], "retracts": []
}
```

- valid_time states when the record applies in the world; recorded_at states when RTracer learned it

- records are immutable; correction uses supersedes, corrects or retracts and preserves the previous statement

- contradictory claims can coexist; a current view declares a trust policy rather than overwriting history

- important operations reference exact before/after or as-operated configurations and evidence

### 14.3 Missing and disputed knowledge

Never let null carry domain meaning. Use explicit states: known, unknown, not_observed, not_measured, unavailable, withheld, redacted, disputed, not_applicable, unsupported_by_current_client and pending_resolution. Preserve the source precision and original vocabulary even when the current application cannot interpret it.

### 14.4 Vocabulary and schema registry

| Registry field | Rule |
| --- | --- |
| Stable ID | Namespaced URI/identifier never repurposed after publication |
| Semantic metadata | Definition, preferred labels, synonyms, language, broader/narrower/equivalent concepts and examples |
| Version | Immutable publication, semantic version, content digest, publisher signature and compatibility declaration |
| Dependencies | Deterministic graph with lock file per configuration/pack set |
| Deprecation | Replacement/mapping and change note; historical records retain original term |
| Migration | Registered adapter plus receipt, information-loss declaration and round-trip fixtures |
| Governance | Owner, reviewers, license, security/privacy annotations and appeal process |
| Promotion | Private/manufacturer term may map into shared vocabulary without rewriting history |

### 14.5 Validation layers

| Layer | Check |
| --- | --- |
| Structural | Payload conforms to declared immutable schema |
| Registry | Schema, term, pack and dependency references resolve |
| Referential | Entities, records, configurations and artifacts exist or are explicitly pending |
| Dimensional | Quantity kinds, units, vectors, frames, ports and flows are compatible |
| Graph | Composition, connectivity, cardinality, topology and cycle rules hold |
| Temporal | Installation, coupling, state, handover and effectivity intervals are coherent |
| Configuration | Snapshot is immutable, complete to its declared resolution and content-hashed |
| Domain | Pack-specific safety, geometry, mass, software, maintenance and approval constraints |
| Integrity | Digest, signature, capture chain and custody checks succeed |
| Authority | Actor may assert, publish, configure or act within a current grant |
| Privacy | Requested projection/export is allowed; precise location and sensitive identifiers fail private |

Validation disposition should be accept, accept-with-warning, quarantine or reject. Contradictory but structurally valid claims are generally retained; corrupt records or unauthorized effects are quarantined or rejected.

### 14.6 Storage boundaries

| Logical store | Responsibility |
| --- | --- |
| Append-only record ledger | Claims, events, observations, grants, receipts and corrections |
| Entity + graph index | Resolution, traversal, search and current/as-of projections |
| Configuration store | Immutable content-addressed configuration graphs and diffs |
| Evidence store | Encrypted/content-addressed documents, photos, scans, signatures and rights metadata |
| Telemetry store | High-volume time series and raw sensor/media chunks |
| Registry | Schemas, vocabularies, domain packs, mappings, signatures and fixtures |
| Policy + grants | Rights, scopes, privacy, consent, delegation and revocation |
| Projection cache | Rebuildable public profile, maintenance, market, race and regulatory views |

Raw telemetry belongs outside the lifecycle ledger. The ledger retains channel schemas, sensor/calibration references, time range, digest, quality summary, configuration/control context and artifact location. This keeps history verifiable without turning the event log into a media or time-series database.

### 14.7 API and export surface

- entity resolution, identifier assertion and time-aware relationship traversal

- append-only record submission, idempotency, correction, dispute and evidence attachment

- configuration create/diff/retrieve and as-of/as-operated queries

- facet search, TypeRecipe matching, explanation and domain-pack discovery

- capability discovery, operating-envelope query and control-assignment history

- action proposal, grant evaluation, approval, execution and receipt

- policy-filtered public/private/regulatory/maintenance/market projection

- portable dossier export containing records, schema/vocabulary locks, configurations, evidence manifest, signatures and rights notes

- canonical JSON for exchange/signing; JSON-LD or equivalent semantic export; binary edge format; columnar analytics export

# 15. Worked edge cases and classification proofs

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.15 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:0082efe28b924385cbcdfe59a94feff68218f0c928e834d73439e5fd01990e54

These examples are conformance proofs for the substrate. None requires a special root class. Each is an ordinary composition of durable identity, facets, graphs, configurations, operations, evidence and domain packs.

### 15.1 Electric scooter, fan-bike, airboat, and water-propeller boat

| Axis | Electric scooter | Fan-propelled bicycle | Airboat | Submerged-propeller boat |
| --- | --- | --- | --- | --- |
| Primary medium | Prepared solid surface | Prepared/off-road solid surface | Surface water | Surface water |
| Support | Two+ ground wheels | Bicycle wheels | Displacement/planing hull | Displacement/planing hull |
| Energy | Battery electricity | Battery or fuel | Battery or fuel | Battery or fuel |
| Converter | Electric motor | Motor/engine | Motor/engine | Motor/engine |
| Force generator | Driven wheel torque | Air propeller/fan thrust | Air propeller/fan thrust | Marine propeller thrust |
| Reaction medium | Ground | Air | Air | Water |
| Steering | Handlebar/lean | Bicycle wheel/lean | Air rudder/vector/differential | Rudder, pod, outboard or differential |
| Decisive fact | Electric traction through wheel | Ground vehicle propelled through air | Water-supported vehicle propelled through air | Water-supported vehicle propelled through water |

### 15.2 KUN — Prague Workhorse

| Graph / record | Example |
| --- | --- |
| Identity | Full-size road VehicleAsset; KUN name assertion; Prague Workhorse persona; owner private; stewards scoped |
| Support | Tires/wheels → axles/suspension → chassis → road reaction |
| Propulsion | Diesel + atmospheric oxygen → engine → transmission → wheel torque → road |
| Action | Carry/tow/work; body, hitch, payload, electrical auxiliaries and tools recorded separately |
| Configuration | Exact chassis/body, engine/driveline, wheels/tires, tracker, firmware, calibration, payload and consumables |
| Whole life | Acquisition, work missions, trips, wash/detail photos, service, repairs, modifications, inspections, interviews and telemetry |
| Agent | Observed data, attributed owner statements and disclosed creative character remain separate truth lanes |
| Market | Profile, valuation, ask, offer, bid and transaction stay different governed objects |

### 15.3 1/8-scale electric RC racer

| Axis | Record |
| --- | --- |
| Identity + scale | Independent PhysicalAsset; model VehicleAsset; scale ratio 1:8; explicit reference design/vehicle; no inherited VIN |
| Support/propulsion | Tires/suspension support; battery → ESC → motor → gearing/differentials → wheel-ground traction |
| Control | Remote driver, transmitter/receiver, servo, command link, failsafe; timing transponder is separate |
| Configuration | Chassis, motor, ESC, receiver, servo, gearing, diffs, suspension geometry, tires, body, battery and calibration |
| Life | Setup sheets, battery cycles/storage, crash/repair, component swaps, cleaning, dyno/temperature, laps and race results |
| Rights + persona | Livery, name and character licensing remain explicit and separable from physical sale |

### 15.4 Blimp

| Graph | Record |
| --- | --- |
| Support | Envelope + lift gas + atmosphere → aerostatic buoyancy; ballonets/ballast/trim regulate state |
| Propulsion | Battery/fuel → motor/engine → air propeller → thrust against air |
| Control | Pilot/remote/autopilot assignments per propulsion, attitude, navigation, mooring and payload function |
| Configuration | Envelope, gas cells, fins, gondola, motors, propellers, batteries, flight control, payload, mass and balance |
| Lifecycle | Envelope hours, leak/pressure checks, gas replenishment, mooring, inspections, repairs, firmware and flight logs |

### 15.5 Tractor + smart trailer + carried rover + drone

Four durable assets form one temporary operational assembly. The tractor tows and may power/control the trailer. The trailer carries the rover and drone, may contribute braking or propulsion, and relays data. Deployment creates new configuration and custody/control relationships; every asset retains its own service, evidence, social and market history.

### 15.6 Underwater glider

The vehicle changes buoyancy to climb and descend; wings convert vertical motion into forward travel. Energy powers pumps/control, but a conventional propeller may be absent. The substrate records hydrostatic support, buoyancy-modulation propulsion, wings, depth/pressure envelope, navigation uncertainty, intermittent communication and surface/recovery phases without forcing it into ‘unpowered’ or ‘propeller boat.’

### 15.7 Transforming rescue machine

Wheel, track, rotor and manipulator modules remain independent component or asset identities. A transformation creates a new immutable topology, geometry, mass/CG, software, support/propulsion/control graph and capability set. Physical movement authority, rescue-tool authority, media publishing and purchasing remain separate mandates.

### 15.8 Rocket stack

Stages, engines, boosters, payload, flight article and recovery systems remain traceable. The launch stack is a temporary assembly. Separation changes composition and propulsion graphs; consumed, discarded, recovered and reused dispositions attach to the relevant stage. Test and telemetry records reference the exact loaded propellant, software, calibration and configuration.

### 15.9 Wheelchair, exoskeleton, and cyborg boundary

```text
Machine identity without human objectification
A wheelchair, powered prosthetic mechanism or exoskeleton may have components, maintenance, telemetry, software, configuration and a public story. The person is a rights-bearing principal, user, operator or beneficiary—never an ownable component, payload record exposed by default, or source of platform authority.
```

# 16. Non-negotiable invariants, conformance tests, and rollout

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.16 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:0dafe9750dce185266ae44032ccf7170a8ccd6384fcc594a7304766d4133dfec

### 16.1 Forty substrate invariants

1. Internal entity identity is opaque, immutable and never keyed by VIN, serial, registration, plate, name, MAC, transponder, owner or account.

1. Design, revision, variant, lot/batch, physical instance, material, feature, software and calibration are distinct.

1. Physical asset, temporary assembly, configuration, component, persona, digital twin, legal party and agent remain distinct.

1. A person or animal is never an ownable component; capability or labor does not erase rights.

1. Self-propulsion is not an admission gate; zero, one or many propulsion paths are valid.

1. Support/lift, propulsion, steering/stopping/stability, useful action and control are separate graphs.

1. Force generator and reaction medium are independent: an air propeller may move a ground or water vehicle.

1. Scale is a quantitative relationship; a model remains an independent real asset and never inherits the referent’s identity.

1. Classification is multi-valued, attributed, configuration/operation-aware and time/jurisdiction/version-bound.

1. A public TypeRecipe is derived from facets; no recipe label alone proves safety, legality, value or fitness.

1. Unknown, absent, not observed, not measured, withheld, disputed and not applicable remain distinct.

1. Every published vocabulary identifier is stable and never repurposed.

1. Unknown namespaces and pack data round-trip without silent coercion or loss.

1. Domain packs extend but cannot redefine kernel identity, time, provenance, evidence, rights or privacy semantics.

1. Every record is typed, schema-versioned and immutable; corrections supersede or retract.

1. Occurred/valid time and recorded time are separate.

1. Every material assertion has a source; important claims link evidence and verification state.

1. Conflicting sourced assertions can coexist until resolved; later does not automatically mean truer.

1. Configurations are immutable, content-addressed and linked by typed diffs.

1. Operations, telemetry, tests, incidents and modifications reference the exact as-operated/as-tested configuration when known.

1. A serialized component retains identity, meters, condition and history when removed, transferred, overhauled or reused.

1. A component cannot occupy exclusive slots over overlapping valid intervals unless explicitly allowed.

1. Composition is acyclic in one snapshot; registered flow/control networks may contain cycles.

1. Every realized connection identifies compatible ports, state, effectivity, tests and evidence.

1. Every physical quantity has quantity kind, unit, source precision, method, reference conditions and uncertainty/frame where meaningful.

1. Derived values retain formula, inputs, algorithm/software version and uncertainty treatment.

1. Autonomy is recorded per function, phase, configuration and operating envelope—not as one vehicle field.

1. Designed, realized, available, authorized, engaged and executed capability are separate states.

1. Momentary protective intervention is not silently classified as sustained automation.

1. Handover is a recorded event with offer, acceptance, functions, timing, fallback and evidence.

1. Physical, publishing, persona, data, market, booking and spending authorities are independent, scoped and revocable.

1. Every consequential action has an authority grant and action receipt.

1. A modification separates reusable design from embodiment and records before/after configuration, actual work, impacts, tests and release.

1. Reverting a change creates another configuration; it never deletes the change history.

1. Defect, damage, fault, failure mode, mechanism, cause, effect and consequence remain distinct.

1. Maintenance due dates and health scores are projections with algorithm, inputs, time and uncertainty—not permanent truth fields.

1. Software identity includes artifact digest, build provenance, dependencies, target compatibility, deployment and rollback state.

1. Creative content cannot self-certify as telemetry, maintenance, ownership, accident, registry or performance evidence.

1. Sensitive identifiers, documents, precise location, raw telemetry and human identity fail private and are filtered server-side.

1. Public, owner, technician, regulator, race, market and twin views are rebuildable projections—not authoritative storage.

### 16.2 Required conformance fixtures

| Fixture family | Golden tests |
| --- | --- |
| Mobility | fan-propelled bicycle; airboat; submerged propeller boat; hovercraft; underwater glider; human/animal/gravity movement |
| Multi-domain | amphibious transition; roadable aircraft; air-water drone; host-carried deployment and recovery |
| Configuration | RC battery/motor reuse; component overlap conflict; temporary tractor-trailer consist; transformation topology |
| Identity | frame/hull/airframe replacement; rebuild from donor parts; replica; split/merge; rocket stage separation |
| Control | mixed human/remote/automation functions; lost link; unsuccessful handover; revoked physical authority |
| Data | offline telemetry with clock drift; contradictory registry assertions; unknown vocabulary/pack preservation |
| Schema | upcast/downcast with declared loss; deterministic projection rebuild; export/import round-trip with stable digests |
| Safety/privacy | unauthorized precise-location view; synthetic media entering factual lane; unsafe modification before release |
| Lifecycle | wash/detail event; repair vs modification; dyno with configuration mismatch; decommission/part-out/reuse |

### 16.3 Build sequence

| Stage | Deliverable | Exit condition |
| --- | --- | --- |
| 0  Kernel lock | Entity, record envelope, evidence, configuration, term/schema registry, rights and privacy | Fan-bike, trailer, blimp and 1/8 RC fixtures fit without special tables |
| 1  Physics + configuration | Facet assertions; support/energy/propulsion/control/action graphs; parts/ports/connections | Exact configuration and graph diffs reproduce every fixture |
| 2  Whole-life record | Maintenance, care, modification, measurements, dyno/tests, failure and condition | KUN can hold a complete trustworthy lifespan |
| 3  Seed packs | Road/KUN, RC/model, marine, air/aerostat, passive/towed and mobile robotics | Each niche gets native fields, validation and onboarding |
| 4  Recipe catalog | Search/onboarding TypeRecipes and explainable matching | Catalog rows derive from facets; unknown machine still onboards |
| 5  Federation | Registry, competition, provider, import/export and dossier adapters | Source semantics, permissions and provenance survive round trip |
| 6  Agent layer | Vehicle voice, truth lanes, social action, commercial mandates and receipts | No social permission can produce physical or financial authority |

### 16.4 First implementation decisions

- Adopt EmbodiedAsset plus multi-role projections instead of one giant Vehicle inheritance tree?

- Adopt TypeRecipe as a versioned constraint set over facet assertions rather than a required single vehicle_type value?

- Lock support, propulsion, action and control as separate graph families?

- Lock immutable configurations and append-only typed records before building more profile fields?

- Select canonical units/quantity vocabulary, JSON signing form and semantic export strategy?

- Approve the first six domain packs and the golden fixtures above?

- Assign vocabulary and schema governance so public terms never drift silently?

- Make the public vehicle profile only one policy-filtered projection over the universal substrate?

```text
Closing proposition
RTracer does not win by naming every vehicle once. It wins by becoming the place where any machine—familiar, niche, hybrid or not yet invented—can acquire a durable identity, exact configuration, whole-life memory, community, voice and governed ability to act.
```

# 17. Semantic precision, evidence lanes, and knowledge state

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.17 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:600fd21fa60bd7a8b356af611d438d4d2dd25137e7f497af1e247b688c764796

The universal model must preserve what was observed, what somebody asserted, what software derived, and what a persona invented. It must also preserve who said it, when it applied, when RTracer learned it, how it was supported, and why a particular view accepted or rejected it. Without those distinctions, a popular story can silently become maintenance history and an imported registry error can overwrite physical evidence.

![Four evidence lanes - observed, asserted, derived and creative - enter validation and are combined by an explicit trust policy into a policy-bound projection.](/substrate/v1.4.1/assets/media/image5.png)

The ledger retains source statements; a view applies its own declared trust and privacy policy.

### 17.1 Record families must not impersonate one another

| Record family | What it means | Minimum proof boundary |
| --- | --- | --- |
| Observation | A sensing or inspection activity produced a result | Sensor/instrument, procedure, phenomenon, feature of interest, result time, valid time, quality and evidence |
| Assertion | An actor or source stated a proposition | Issuer, subject, predicate/value, scope, source artifact, effective interval and authority context |
| Derived claim | A reproducible method transformed inputs into an output | Input record IDs, algorithm/formula, model/software version, parameters, uncertainty and execution receipt |
| Classification | A scheme assigned a term or class | Scheme/version, authority, jurisdiction, configuration/operation scope, decision basis and status |
| Decision | An authorized actor selected a disposition | Decision maker, options, rule/criteria, inputs, time, scope and appeal/supersession path |
| State interval | A property held over a declared time span | State axis, start/end evidence, confidence, configuration and correction lineage |
| Event | Something bounded happened | Participants, roles, valid/recorded time, place/privacy, cause links, outcome and evidence |
| Creative artifact | A story, persona expression or synthetic media object | Canon/brief, generator/editor, disclosure, rights, source citations and prohibited factual promotions |

### 17.2 Orthogonal epistemic axes

| Axis | Seed vocabulary | Question answered |
| --- | --- | --- |
| Truth lane | observed; asserted; derived; creative | What kind of statement is this? |
| Knowledge state | known; unknown; not_observed; not_measured; unavailable; withheld; redacted; disputed; indeterminate; not_applicable | Why is there or is there not a value? |
| Verification state | unverified; syntax_checked; integrity_checked; source_authenticated; authority_checked; corroborated; independently_reproduced; contested | What checks actually occurred? |
| Confidence | probability, interval, ordinal assessment or explicitly unscored | How strongly does the producer believe the claim? |
| Evidence coverage | none; partial; direct; indirect; composite | How much of the proposition is supported by linked evidence? |
| Source role | maker; owner; custodian; operator; maintainer; authority; insurer; organizer; sensor; witness; importer; analyst; AI system | Who produced it and in which role? |
| Status | draft; active; superseded; retracted; rejected; quarantined; expired | How should readers treat this record now? |
| Disclosure | public; community; team; owner; technician; authority; escrow; private; sealed | Who may receive the payload or a redacted projection? |

```text
Confidence is not verification
A model may be highly confident and wrong. A signed source may be authentic and still mistaken. A regulator may be authoritative only inside one jurisdiction. Store each dimension separately; never compress them into one trust_score.
```

### 17.3 Bitemporal and corrective semantics

| Field / relation | Required meaning |
| --- | --- |
| valid_time | When the proposition or state applied in the world; may be an instant, interval or uncertain interval |
| recorded_at | When RTracer accepted the record into custody; never backdated |
| source_created_at | When the source artifact says it was created, with source clock and reliability |
| observed_at / result_time | When sensing occurred versus when a result became available |
| available_from / embargo_until | When a projection may expose the record |
| supersedes | A later statement replaces a prior statement under a declared context without deleting it |
| corrects | A later record fixes an error and states the corrected fields and reason |
| retracts | Issuer withdraws support; the old record remains in history |
| disputes | Another actor challenges all or part of a record and supplies a basis |
| corroborates | Independent evidence supports a bounded proposition; it does not automatically validate unrelated fields |
| derived_from | Output depends on immutable inputs and a reproducible transformation |
| caused_by / contributed_to | Causal hypothesis or established relation with strength, method and reviewer |

```text
Canonical assertion - fields stay explicit
{
  "record_type": "rtracer.claim/facet-assertion@1",
  "subject_ref": "asset:kun-prague-workhorse",
  "predicate_ref": "rtracer.mobility.force_generator",
  "value_ref": "rtracer.force.driven_wheel",
  "truth_lane": "asserted",
  "knowledge_state": "known",
  "verification_state": ["source_authenticated"],
  "scope": {"configuration_ref": "cfg:kun:2026-07-22"},
  "valid_time": {"from": "2026-07-22T00:00:00Z"},
  "recorded_at": "2026-07-22T03:00:00Z",
  "issuer_ref": "party:maintainer-example",
  "evidence_refs": ["sha256:..."],
  "confidence": {"kind": "ordinal", "value": "high"},
  "visibility_policy_ref": "policy:owner-team"
}
```

### 17.4 Trust-policy projection algorithm

1. Select records by subject, valid time, recorded time, configuration, operation, jurisdiction and audience.

1. Verify schema, vocabulary, digest, signature, custody and source resolution; quarantine malformed or untrusted artifacts.

1. Apply authority scope: a source can be authentic but not authorized to establish that proposition.

1. Group records by proposition and preserve support, contradiction, retraction, correction and uncertainty links.

1. Apply the projection's declared source precedence and corroboration rules; never use an invisible global ranking.

1. Produce a value, set of values, range, conflict, unknown state or withheld/redacted marker with an explanation graph.

1. Attach the exact policy/version, input record IDs, as-of times and transformation receipt so the view can be rebuilt.

# 18. Identity continuity, quantities, coordinates, geometry, and scale

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.18 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:fdb276cc54c97c1840a8fb6d5a1fe1e02e430e64c0e5178cc882b36c39e0b038

A universal system must survive serial-number changes, donor parts, replacement frames, stage separation, transforming geometry and contradictory measurements. Identity continuity is a governed decision; physical state is expressed with units, reference frames, uncertainty and time. Neither is safely represented by a mutable row of convenient values.

### 18.1 Identity continuity decision record

| Field | Required content |
| --- | --- |
| Subjects | predecessor, candidate successor(s), donor assets, removed assemblies and legal records |
| Trigger | repair, rebuild, replacement shell/frame/hull/airframe, split, merge, stage separation, repurpose, recovery or replica discovery |
| Competing continuity bases | legal identity; manufacturer identity; load-bearing structure; functional continuity; community provenance; custody; digital/persona continuity |
| Policy | jurisdiction/domain/organization policy and version; mandatory versus advisory |
| Evidence | marks, documents, photographs, scans, material/forensic tests, work records, ownership chain and witness statements |
| Decision | same identity; successor identity; new identity; split identities; merged assembly only; indeterminate; disputed |
| Consequences | identifier mappings, meter/life inheritance, warranties, approvals, title, market history, persona, followers and disclosure |
| Review | decision maker, authority, date, confidence, dissent, appeal, supersession and public/private explanation |

### 18.2 Difficult continuity cases

| Case | Default modeling stance | Must remain explicit |
| --- | --- | --- |
| VIN/chassis plate replaced | Internal asset ID does not change automatically | Legal re-identification, plate custody, authority decision and fraud checks |
| Frame/hull/airframe replacement | Create before/after configurations and request continuity decision | Structural provenance, regulatory rule, donor identity and market disclosure |
| Restoration from many donors | Track every donor component and create or confirm root identity | What survived, what was reproduced, lineage uncertainty and authenticity claims |
| Rocket stage separation | Each stage may already be an asset; stack identity ends or changes | Membership, control, custody, consumed/recovered disposition and mission lineage |
| Vehicle split into two builds | One predecessor can produce several successor candidates | Which history and rights each successor inherits; no automatic duplication |
| Two wrecks merged | Do not silently pick the most valuable identity | Legal basis, dominant structure, donor history, disclosures and dispute state |
| Battery repurposed | Battery instance persists; role and passport responsibility change | Original and new passports, state-of-health, safety, custody and use history |
| Model or replica | Always a distinct physical identity | Represents relationship, scale/fidelity, licensed livery/persona and no inherited VIN/history |
| Persona transferred | Persona rights may move without moving physical identity | Canon, followers, likeness/license, old/new host disclosure and revenue rights |
| Digital twin fork | Create a new digital artifact lineage | Data cutoff, model assumptions, source asset and synchronization authority |

### 18.3 QuantityValue contract

| Field | Rule |
| --- | --- |
| quantity_kind_ref | Stable semantic quantity such as torque, shaft power, displaced volume or remaining-energy estimate |
| value_shape | scalar; vector; matrix/tensor; interval; time series; distribution; categorical result |
| original_value + unit | Exact received representation, precision and source unit; never discarded after normalization |
| canonical_value + unit | Optional normalized value plus conversion-registry/version and rounding method |
| tolerance | Design/manufacturing/acceptance tolerance, distinct from measurement uncertainty |
| uncertainty | Standard/expanded uncertainty, confidence interval, covariance or declared unknown |
| reference_conditions | Temperature, pressure, density, humidity, fuel, state of charge, correction standard and load |
| frame + datum | Coordinate frame, origin, axes, handedness, datum, epoch and transform chain |
| method + instrument | Procedure/revision, sensor/instrument instance, range, resolution and calibration |
| time | Phenomenon/result time, duration, sample clock, time zone and synchronization quality |
| configuration | Exact as-measured/as-tested configuration, software, calibration, payload and control mode |
| quality | validity flags, saturation, dropout, interpolation, filtering, outlier treatment and reviewer |
| derivation | Formula/model, inputs, implementation version and uncertainty propagation |

### 18.4 Coordinate-frame and transform graph

| Frame family | Required definition |
| --- | --- |
| Asset body | Root rigid-body frame; origin and orientation convention locked by design/configuration |
| Component local | Frame attached to a component occurrence or articulated link |
| Sensor / camera | Optical/acoustic/radar/instrument frame plus calibration and covariance |
| Tool / work target | End-effector, tool-center-point, workpiece or interaction frame |
| Payload / occupant | Mount, restraint, cargo, center-of-mass or seating reference frame |
| Route / track / guideway | Chainage, lane, rail, cable, pipe, tunnel or mission-path coordinate |
| Local map | Site/world frame with map version, origin and drift/alignment history |
| Geodetic | Latitude/longitude/height with datum, ellipsoid, geoid and epoch |
| Marine | Chart datum, waterline, depth-positive convention, tide/current reference |
| Aerospace inertial / Earth-fixed | Inertial and rotating frames, time standard and transform source |
| Orbital / celestial | Central body, reference plane, epoch, element/state representation and propagator |

- Transforms are first-class, time-varying records with source, calibration, interpolation, covariance and validity interval.

- A point without a frame is incomplete; altitude without a vertical datum is ambiguous; heading without north/reference convention is ambiguous.

- Articulated and deformable machines require joint states, constraints and a configuration-specific kinematic model rather than one static body frame.

- Privacy projections can transform or fuzz coordinates, but the transformation and disclosure policy must remain auditable.

### 18.5 Geometry, envelope, mass properties, and scale

| Representation | Purpose | Key semantics |
| --- | --- | --- |
| Nominal dimensions | Search, compatibility and regulation | Configuration/mode, reference points, tolerance, loaded/unloaded state |
| Bounding volume | Storage, route, transport and collision checks | Axis-aligned/oriented box, cylinder, hull or custom volume in a named frame |
| Detailed geometry | Design, scan, simulation and fabrication | Format/version, unit, frame, topology, level of detail, digest and rights |
| Swept volume | Turning, articulation, rotor/wing/tool motion and clearance | Joint/mode trajectory, safety margin and environment |
| Reach/work envelope | Manipulator, crane, tool, sensor and payload capability | Configuration, load, precision, exclusions and collision zones |
| Contact/support geometry | Tire patch, track, foot, hull, foil, wing, mooring or rail contact | Surface/medium, compliance, load distribution and state |
| Mass properties | Dynamics, balance, support and safety | Mass, CG/CB, inertia tensor, load case, consumables and uncertainty |
| Scale relationship | Model, replica and similarity | Reference design/asset, geometric/mass/time/force ratios and fidelity dimensions |

```text
Scale is not one number
A 1:8 body can use non-scale tires, battery, motor, mass distribution, control latency or aerodynamic Reynolds regime. Record geometric, mass, kinematic, dynamic, control, appearance and mission fidelity independently, with the referenced design or asset.
```

# 19. Deep physical mechanism grammar

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.19 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:e9c1f7c3bf9d09b06ab8fea31e57cdd5de0d0afbc236637c1743ff3e30da10af

The first edition separated support, propulsion and useful action. This section defines the parameter grammar inside those graphs so that rare mechanisms remain queryable and comparable. A mechanism is modeled by what resource enters, what physical conversion occurs, which force or moment is produced, what interface transfers it, which medium or structure reacts, and what motion or work results.

```text
Mechanism path contract
source -> storage/feed -> conditioner -> converter -> transmission -> force/moment generator -> interaction interface -> reaction medium/body -> motion or work; every node and connection is configuration-, mode-, time-, and evidence-bound.
```

### 19.1 Support-path fields

| Field | Controlled semantics |
| --- | --- |
| supported_body / load_set | Body, occupants, payload, working loads, distributed loads and transient loads supported |
| support principle | normal reaction; tension; compression; buoyancy; aerodynamic/hydrodynamic lift; pressure cushion; electromagnetic force; orbital/free-fall state |
| support interface | wheel, tire, track, foot, body, ski, skid, rail wheel, hull, foil, wing, rotor, envelope, cable, field or carrier |
| reaction medium/body | surface material, rail/guideway, water, air, cable/structure, field source, another vehicle or central-body gravity |
| contact topology | point/line/area, discrete/continuous/intermittent, contact count, stance/gait, wetted area and current state |
| load transfer | forces/moments, distribution, direction, preload, compliance, damping, pressure and load path |
| support state | static, rolling, sliding, planing, foiling, hovering, airborne, submerged, tethered, docked, carried or transitioning |
| limits | capacity, pressure, slip, sinkage, flotation/lift margin, clearance, stability, environment and failure state |

### 19.2 Locomotion pattern lexicon

| Pattern family | Seed patterns | Discriminator |
| --- | --- | --- |
| Continuous surface | roll; slide; skid; ski; skate; track; belt; drum; screw/auger | Contact remains substantially continuous |
| Discrete foothold | walk; run; trot; gallop; crawl; climb; brachiate; hop; jump | Gait and contact sequence generate translation |
| Whole-body | slither; undulate; sidewind; inchworm; peristalsis; concertina; tumble; roll body | Body deformation or reorientation is the propulsor |
| Micro/vibratory | bristlebot; vibration; inertial stick-slip; cilia; surface-tension/capillary | Small periodic effects rectify into motion |
| Aquatic cyclic | swim; flap; oscillate fin/fluke; paddle; row; scull; pulse jet | Periodic momentum exchange with fluid |
| Aerodynamic | glide; soar; flap; hover; autorotate; parachute; kite | Lift/drag fields and gravity participate in motion |
| Buoyancy cycle | underwater glide; balloon altitude cycle; thermal soaring | Vertical buoyancy/thermal change becomes lateral progress |
| Momentum ejection | jet; rocket; cold gas; mass driver; reaction control | Working mass leaves the vehicle |
| External path | tow; push; winch; cable haul; catapult; gravity descent; carrier release | Prime motive force originates outside the asset |
| Field / radiation | linear motor; magnetic pull/repulsion; solar sail; electric sail; electrodynamic tether | External field or radiation supplies reaction |
| Free trajectory | ballistic; drift; coast; orbit; free-fall; station-keeping arc | Motion can persist with no active locomotion mechanism |
| Transforming | wheel-to-leg; wheel-to-track; ground-to-flight; fold/deploy; stage/separate | Locomotion family changes through a recorded transition |

### 19.3 Propulsor classification by physical reaction

| Reaction class | Examples | Required distinction |
| --- | --- | --- |
| Solid surface traction | wheel, track, roller, foot, gripping body | Normal load, friction/adhesion, slip, sinkage and surface deformation |
| Fixed guideway reaction | rail wheel, rack, linear motor, cable grip | Gauge/path compatibility, adhesion or electromagnetic/cable reaction |
| Air accelerated externally | open propeller, fan, ducted fan, rotor, cyclorotor | Air is accelerated; support medium can still be land or water |
| Air-breathing internal flow | turbojet, turbofan, ramjet, pulsejet | Ambient air ingested, conditioned/combusted and exhausted |
| Water accelerated externally | submerged/surface-piercing propeller, paddlewheel, oar, fin | Momentum exchanged directly with surrounding water |
| Water internal flow | waterjet, pump-jet, tunnel thruster | Water is ingested through an internal path and discharged through a nozzle |
| Ambient-flow extraction | sail, kite, rigid wing sail, current/wave device | Wind/current supplies energy; append active storage only if present |
| Onboard working mass | rocket, cold gas, ion, Hall, electrospray, steam/water impulse | Vehicle expels carried reaction mass; oxidizer/intake distinction explicit |
| External mechanical link | towline, pushbar, cable, launch rail, catapult | Force crosses a coupling boundary from another actor/system |
| Electromagnetic / radiation | linear motor, magnetic sail, solar sail, beamed sail, electrodynamic tether | Interaction with externally sourced field/radiation |
| Buoyancy / gravity | variable-buoyancy glider, balloon cycle, downhill/coasting, gravity-assist | Potential-energy or buoyancy change supplies part of motion |
| Internal momentum only | reaction wheel, control-moment gyro, moving mass | Changes attitude or internal distribution; cannot create net translation in free space alone |

### 19.4 Steering, retardation, stability, and holding paths

| Path | Mechanism seed |
| --- | --- |
| Geometric steering | steered axle/wheel, caster, articulation, bendable body, differential track geometry |
| Differential force | skid steer, torque vectoring, differential propeller/rotor/jet thrust, brake steering |
| Fluid control surface | rudder, elevator, aileron, canard, fin, diving plane, sail/foil trim |
| Vector/reorient propulsor | azimuth pod, outboard, gimbal, thrust vector, tiltrotor, cyclic/collective |
| Mass/buoyancy/drag shift | movable mass, ballast transfer, trim tank, drogue, spoiler, air brake |
| Retardation | friction, regenerative, engine/compression, eddy-current, aerodynamic/hydrodynamic drag, reverse thrust |
| Holding | parking brake, pawl, chock, anchor, mooring, magnetic hold, station keeping, hover/loiter |
| Passive stability | trail/caster, keel, dihedral, low CG, fin, restoring buoyancy, suspension geometry |
| Active stability | ESC, active suspension, flight controller, gyro/CMG, ballast controller, dynamic positioning |
| Failure response | neutral, brake, hold, surface, land, anchor, safe descent, parachute, passivate or separate |

### 19.5 Multi-resource and replenishment graph

| Stage | Vocabulary seed |
| --- | --- |
| Origin | onboard stored; externally supplied; harvested ambient; biological; nuclear; gravitational/kinetic |
| Carrier / reactant | electric charge; liquid/gas/solid fuel; hydrogen; oxidizer; compressed gas; hydraulic fluid; heat; working mass; human/animal effort |
| Storage / buffer | battery; capacitor; tank; pressure vessel; accumulator; flywheel; thermal store; propellant grain; raised mass |
| Feed / conditioning | pump; regulator; injector; inverter; rectifier; transformer; valve; BMS; fuel/oxidizer management; thermal conditioner |
| Converter | motor; combustion/steam engine; turbine; fuel cell; PV; hydraulic/pneumatic motor; rocket chamber; muscle |
| Distribution | shaft; gears; chain/belt; hydraulic/pneumatic network; electrical bus; power split; distributed drives |
| Recovery | regenerative braking; windmilling; thermal recovery; solar recharge; gravitational recovery; tow regeneration |
| Replenishment | refuel; recharge; swap; refill gas/oxidizer/fluid; tether supply; harvest; service; in-flight/in-motion transfer |
| Reject/byproduct | heat; exhaust; water; noise; vibration; wake; plume; radiation; discharged material; spent component |

Create separate but linkable resource paths for propulsion, lift/support, tools, computing, cabin/hotel loads, environmental control, life support, safety, payload and thermal management. Hybrid means more than two energy carriers: a sailboat with diesel auxiliary, a solar-assisted e-bike, a tether-powered drone with backup battery and a rocket stage with separate propellants are all multi-path systems.

### 19.6 Domain-transition state

| Field | Required content |
| --- | --- |
| from_mode / to_mode | Named configuration and operational modes; both can be composite |
| entry envelope | speed, depth/altitude, position, surface state, load, weather, health, energy and authority |
| topology changes | deploy/retract, couple/separate, flood/vent, ballast, fold, seal, lock and software mode |
| support transfer | Which support paths accept load, in which sequence, with overlap and margin |
| propulsion transfer | Which force paths start/stop and how thrust/torque/flow is blended |
| control handover | Controller, function, acknowledgment, command continuity and fallback |
| hazard gates | Doors/hatches, propulsor guards, pressure, clearance, stability, collision and abort criteria |
| intermediate state | A real state with its own limits; never hidden as an instantaneous enum change |
| completion | Resulting configuration digest, active graphs, checks, anomalies and evidence |

# 20. Control authority, autonomy, operations, and fallback state

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.20 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:5e1197815dcf8bd12e3cf0c843a128045553e3b205730357b3b2fb255a921a84

Control is the allocation of sensing, deciding, commanding, monitoring and recovering for a named function in a named phase. Capability, legal permission, technical readiness, engagement and actual execution are separate. The same blimp can have automated attitude stabilization, remote propulsion, human mission approval and an independent onboard emergency controller at the same moment.

![Eight-stage control authority state machine from proposed through authorized, armed, engaged, executing, degraded, fallback and closed.](/substrate/v1.4.1/assets/media/image6.png)

Authority and execution are eventful states; revocation and envelope exit can force a transition at any time.

### 20.1 Controlled-function register

| Function family | Examples |
| --- | --- |
| Mission | accept job; plan mission; select objectives; reprioritize; terminate |
| Route / trajectory | route, path, waypoint, orbit, berth, docking corridor and transition selection |
| Tactical motion | lane/path choice, obstacle response, right of way, formation spacing and collision avoidance |
| Stabilization | attitude, trim, speed, altitude/depth, lateral/vertical stability and traction |
| Propulsion | start/stop, torque/thrust/power, direction, propulsor allocation and limits |
| Steering / attitude | directional and rotational command across wheels, surfaces, thrust, ballast or body |
| Stop / hold | brake, anchor, park, hover, loiter, station keep, safe descent and shutdown |
| Domain transition | deploy/fold, ballast/flood, launch/recover, couple/separate and mode handover |
| Energy / thermal | source selection, reserve, charging/refueling, load shed, cooling and emergency power |
| Payload / tool | arm, position, operate, release, manipulate, spray, lift, film, sample and stow |
| Perception / data | sense, record, classify, transmit, redact, retain and expose telemetry/media |
| Safety | limit, veto, emergency stop, isolate, contain, recover, evacuate and distress |
| Social / persona | draft, speak, post, reply, follow, invite, disclose synthetic media and moderate |
| Commercial | list, bid, book, quote, purchase, sell, invoice, receive revenue and reconcile |

### 20.2 ControlAuthorityAssignment

| Field group | Required content |
| --- | --- |
| scope | function(s), phase, asset/assembly, configuration, operation, geography/domain and time interval |
| controller | human, onboard automation, remote automation, infrastructure, peer, leader, fleet agent or independent safety controller |
| authority role | observe; advise; propose; approve; limit; veto; command; override; emergency stop; configure |
| command abstraction | actuator; force/torque; rate; speed/attitude; trajectory; path; waypoint; task; goal; mission; constraints/policy |
| feedback closure | open loop; human closed; onboard closed; remote closed; infrastructure closed; distributed |
| allocation | exclusive, shared, blended, hierarchical, priority, consensus, veto or arbitration policy |
| supervision | continuous control, continuous monitoring, intermittent supervision, alert response, approval, dispatch, none |
| communications | link, direction, latency/jitter, bandwidth, availability, authentication, redundancy and loss behavior |
| operating envelope | ODD/domain definition, current-domain monitor, margins, prohibited conditions and exit detection |
| fallback | trigger, performer, response deadline, behavior, safe state, recovery path and evidence |
| authority grant | principal, purpose, rights, limits, approval requirement, budget/rate and revocation |
| implementation lock | software/model/calibration/configuration versions and safety partition |

### 20.3 Functional independence vector

| Function | Meaning |
| --- | --- |
| Sense | Acquire raw signals or human observations |
| Perceive | Detect/classify objects, state, events, conditions or work targets |
| Localize | Estimate pose, time and uncertainty in one or more frames |
| Predict | Estimate future state, behavior, risk, wear or resource use |
| Plan | Generate routes, trajectories, task sequences, resource plans or content plans |
| Decide | Select an action under constraints and authority |
| Command | Produce a bounded setpoint, task, goal or action request |
| Actuate | Create physical/digital effect through an interface |
| Monitor | Compare expected and actual state, health, envelope and authority |
| Diagnose | Identify fault, cause, conflict, uncertainty or missing prerequisite |
| Recover | Replan, reallocate, fallback, hold, stop, return or repair |
| Coordinate | Negotiate or synchronize with people, peers, infrastructure or a fleet |
| Learn/adapt | Offline update, bounded online adaptation or open-ended learning with approval state |
| Explain/receipt | Expose inputs, policy, decision, action, result and unresolved uncertainty |

For every controlled function, allocate each step above to an actor/system and record whether it is designed, available, authorized, engaged and evidenced. This produces a comparable control vector without pretending that road, marine, aerial, space, industrial and social autonomy share one ladder.

### 20.4 Handover, arbitration, and fallback events

| Event / area | Required semantics |
| --- | --- |
| Handover offer | offering controller, functions, current state, reason, deadline, required recipient capability |
| Readiness | recipient identity, attention/health/link state, situational context and acceptance criteria |
| Acceptance | explicit acknowledgment, functions accepted, limits, effective time and unresolved exceptions |
| Command continuity | last command, neutralization, state synchronization, double-command prevention and ownership token |
| Arbitration | priority, veto, deadlock resolution, tie-breaker, safety-controller precedence and audit log |
| Failed handover | trigger, timeout, minimum-risk behavior, alerts, escalation and recovery |
| Fallback execution | performer, safe behavior, achieved state, deviations, residual hazard and action receipt |
| Return of authority | re-entry conditions, checks, new assignment and re-engagement evidence |

### 20.5 Communications dependency profiles

| Profile | Meaning | Loss-of-link requirement |
| --- | --- | --- |
| Independent | Function does not require an external link while active | Continue within local authority and envelope |
| Optional enhancement | Link improves data or supervision but is not required | Degrade service; preserve safe function |
| Start authorization | Link required to arm/start but not continuously | No new mission/phase after authorization expires |
| Periodic lease | Authority renewed by heartbeat or lease | Grace period then named fallback |
| Continuous supervisory | Remote/infrastructure supervision required | Bounded response based on latency and safe-state feasibility |
| Remote closed loop | Human/offboard controller closes the motion or tool loop | Immediate local stabilizer/neutral/stop/hold response |
| Tethered control/power | Physical/data/energy tether is part of operation | Detect break, isolate, preserve buoyancy/landing/holding state |
| Delayed/disconnected | Space, underwater or underground link is intermittent by design | Store-and-forward plus onboard bounded autonomy and timed contingency |

### 20.6 Multi-asset coordination

| Pattern | Required distinction |
| --- | --- |
| Dispatcher | Central service assigns jobs; each asset executes locally |
| Leader-follower | Leader provides path/state; followers retain local safety and spacing |
| Platoon/convoy | Coordinated longitudinal/lateral motion with membership and join/leave protocol |
| Parent-child | Carrier deploys, tasks, monitors and recovers a subordinate vehicle |
| Peer cooperative | Assets exchange intentions/state and negotiate tasks or collision avoidance |
| Centralized swarm | Coordinator allocates formation/tasks; local agents execute |
| Distributed swarm | Collective behavior emerges from peer/local rules; membership and rule version explicit |
| Infrastructure managed | Traffic, guideway, warehouse, launch, port or airspace system controls allocation |
| Human multi-asset | One operator supervises many assets with workload, alert and takeover limits |

### 20.7 Cross-domain control examples

| Asset / phase | Function allocation | Critical boundary |
| --- | --- | --- |
| KUN road drive | Human steering/propulsion; electronic engine/brake assistance; independent protective limits | Social agent receives read-only telemetry and no actuator authority |
| RC racer | Remote human trajectory intent; onboard stabilization and failsafe neutral/brake | Radio loss, track geofence, marshal recovery and battery state |
| Blimp cruise | Remote/supervisory mission; onboard attitude/altitude loops; ground crew for mooring | Wind envelope, lost link, lift/ballast state and recovery site |
| Underwater glider | Supervisory mission upload; onboard buoyancy/trim/navigation; intermittent acoustic/satellite contact | Depth/pressure/energy envelope and timed surface contingency |
| eVTOL passenger mission | Function-specific flight automation under certified/authorized operation | Do not infer global autonomy from one feature; diversion/landing fallback explicit |
| Warehouse swarm | Fleet scheduler assigns tasks; local navigation; infrastructure zones and human safety controller | Membership, traffic priority, e-stop and one-to-many supervision load |
| Vehicle persona | Agent drafts/replies inside canon; human or policy approves sensitive posts; transaction skills separately granted | No media, social or commerce grant crosses into physical motion control |

# 21. Whole-life engineering digital thread

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.21 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:5073590fa8c04bb3504417d67e82b7fd8b50358db85533cb06e55c5b7afcc9ec

The lifespan is not a feed of notes. It is a linked digital thread from design intent through manufacture, commissioning, operation, care, service, modification, transfer, restoration, repurpose and retirement. Every important change connects an exact baseline to an exact result while preserving the parts, people, tools, materials, software, evidence, rights and approvals involved.

![Twelve-phase vehicle lifecycle from design and build through operation, care, maintenance, modification, verification, transfer, restoration, repurpose and retirement.](/substrate/v1.4.1/assets/media/image7.png)

The asset remains durable while configuration, state, condition, custody and approvals change on separate planes.

### 21.1 Five state planes

| State plane | Changed by | Examples |
| --- | --- | --- |
| Design baseline | Released design revision, approved deviation or waiver | Wing revision, gearbox definition, harness drawing, software requirement |
| Realized configuration | Installation, removal, connection, material load, deployment or software/calibration assignment | Battery swap, new propeller, temporary camera, firmware deployment |
| Operational state | Normal operation, motion, mode or resource change | Joint angle, landing gear position, tank level, road/water mode, controller engaged |
| Condition state | Wear, inspection, damage, fault, contamination or repair assessment | Corrosion, tire wear, low battery health, crack, fouling, finish condition |
| Legal / approval state | Authority, organizer, insurer or owner decision | Airworthiness, road authorization, race eligibility, deferred defect, restriction |

```text
Avoid snapshot explosion
A robot moving a joint does not create a new engineering configuration every millisecond. The installed topology stays in ConfigurationSnapshot; pose and resource values belong in OperationalStateSnapshot. A discrete, safety-gated transformation can reference a MorphModeDefinition and a resulting configuration only when topology or controlled effectivity truly changes.
```

### 21.2 Configuration-item kinds

| Item kind | Identity behavior |
| --- | --- |
| Design definition / revision | Intended product, part, material, feature, software, task or test definition |
| Physical serialized instance | Individually traceable frame, engine, battery, propeller, wheelset, controller or tool |
| Lot / batch | Shared manufacturing/material provenance without individual serialization |
| Integral feature | Hole, weld, adhesive bead, coating layer, repair patch, reinforcement or machining feature |
| Bulk material / substance | Fluid, gas, coating, adhesive, propellant, lubricant, ballast, feedstock or mixture |
| Consumable / life item | Filter, tire, brake material, desiccant, chemical, sealant or component depleted by use |
| Software / firmware | Exact signed executable, package, library, operating system, rules or map artifact |
| Calibration / parameter set | Versioned values, maps, curves, limits, learned parameters and target compatibility |
| AI model / persona artifact | Weights/service digest, runtime, inputs/outputs, evaluation, domain, limitations and authority class |
| Data / content artifact | Technical document, CAD/mesh, test data, manual, media, canon, prompt or evidence bundle |
| Tooling / support equipment | Fixture, charger, diagnostic tool, launch/recovery gear, mold, stand or transport cradle |
| Temporary payload / attachment | Mission kit, camera, cargo module, implement, carried vehicle or leased attachment |

### 21.3 Parallel BOM and structure views

| View | Question |
| --- | --- |
| Engineering BOM | What does the released design define? |
| Manufacturing BOM / process | What is built, in what sequence, with which materials and tooling? |
| Procurement / supplier | What can be sourced, substituted, certified, costed and warranted? |
| Service / illustrated parts | What is maintained, removed, replaced, inspected and provisioned? |
| Software / calibration | What artifacts, dependencies, targets, partitions and parameters are required? |
| Material / substance | What grades, lots, compositions, regulated substances and mixtures are present? |
| Mass / balance | Which items and loads contribute to mass, CG/CB and inertia? |
| Cost / carbon | Which costs and environmental impacts are allocated under which method/boundary? |
| As-built / as-delivered | What physical configuration left production and entered custody? |
| As-maintained / as-repaired | What does service evidence say is installed and repaired? |
| As-operated / as-tested | What exact build, load, software, settings and connections produced the operation/result? |
| As-retired | What was removed, harvested, destroyed, recycled, retained or transferred? |

- BOM membership never proves installation; a realized placement and installation event are required.

- One item can appear in product, function, location, power, fluid, data, control, safety, maintenance, ownership and certification structures simultaneously.

- A configuration node can reference an item, material quantity, feature, software, calibration or data artifact; edges carry typed placement, connection and effectivity.

- Exclusive slot occupancy cannot overlap. Shared cloud services, broadcast signals and non-exclusive functional providers use explicitly non-exclusive relations.

### 21.4 Effectivity and applicability

Applicability must evaluate to TRUE, FALSE, UNKNOWN or ERROR. Missing serial, configuration, jurisdiction or software data cannot become FALSE and cannot authorize work. Expressions may combine time, identifier ranges, design revisions, installed items, quantities, versions, relationships, jurisdiction, operation mode and namespaced domain operators.

| Operator family | Examples |
| --- | --- |
| Boolean | ALL, ANY, NOT, XOR with explanation tree |
| Comparison | EQ, NEQ, GT/GTE, LT/LTE, BETWEEN, IN |
| Presence | EXISTS, IS_UNKNOWN, HAS_COMPONENT, HAS_MODIFICATION, HAS_PORT |
| Version | VERSION_EQ, VERSION_RANGE, REVISION_AT_LEAST, DIGEST_EQ |
| Temporal | BEFORE, AFTER, DURING, OVERLAPS, METER_SINCE, EVENT_SINCE |
| Quantity | Dimension-aware unit conversion, range, tolerance and uncertainty |
| Graph | CONNECTED_TO, INSTALLED_IN, POWERED_BY, COUNT, ALL_MEMBERS, ANY_MEMBER |
| Context | JURISDICTION_IN, DOMAIN_MATCHES, OPERATION_MODE_IN, CONTROL_MODE_IN |

### 21.5 Maintenance program and task anatomy

| Layer | Required content |
| --- | --- |
| Strategy | calendar/usage/cycle preventive; event-triggered; condition-based; predictive; opportunity; corrective; emergency; inspection; calibration; care; preservation; overhaul; directive/recall |
| Trigger / interval | calendar, distance, hours, starts, landings, laps, missions, pressure/thermal cycles, charge-equivalent cycles, throughput, exposure, condition threshold or named event |
| Applicability | target selector, configuration, design revision, installed options, software, jurisdiction, duty and environmental state |
| Prerequisites | isolation, safe state, access, cleanliness, environment, tools, support equipment, skills and permits |
| Procedure | ordered steps, warnings, parameters, target, hold points, witnesses, conditional branches and evidence |
| As found | condition, measurements, findings, contamination, faults, photos/scans and uncertainty |
| Work execution | actual workers, times, steps, parts, lots, materials, tools, deviations, interruptions and signoffs |
| Close / release | as-left condition, measurements, tests, unresolved findings, limitations, release authority and next due |

```text
Meter rules
Distance, time, cycles, starts, launches, landings, pressure events, energy throughput and component-specific meters are independent. Resetting, replacing or overhauling never erases the prior reading. A component carries its meters when removed and reused; zero-time or life-reset status requires an explicit policy and authority.
```

### 21.6 Care, wash, detailing, and preservation execution

| Area | Record fields |
| --- | --- |
| Target + condition | surface/zone/component, configuration, contamination before, finish/coating and protected ports |
| Activity | rinse, hand/touchless/pressure/steam wash, degrease, decontaminate, polish, correct paint, coat, disinfect, defoul, preserve or depreserve |
| Materials | product/lot, pH, dilution, water source/hardness, pad/brush/media and compatibility |
| Process | temperature, pressure, nozzle, stand-off, dwell, agitation, abrasive grade, drying and masking |
| Environment + waste | location/privacy, weather, energization, runoff capture, waste, biosecurity and jurisdiction |
| Evidence + findings | before/during/after media, gloss/thickness/roughness, newly exposed damage and public derivative |
| Outcome | condition after, protection applied, cure/expiry, cost, provider, next care and story rights |

The same contract supports a car-wash photo, salt removal from a truck, aircraft wash, underwater hull biofouling removal, blimp-envelope cleaning, RC-car bearing protection and museum conservation. A care task can finish successfully while independently creating a defect record when cleaning reveals damage.

### 21.7 Modification, fabrication, and tuning

| Layer | Required content |
| --- | --- |
| Definition | purpose, baseline/effectivity, planned change operations, target outcome, interface/material/software deltas and rollback |
| Impact assessment | mass/CG/inertia, structure/fatigue, energy/range, thermal, handling, braking, safety, reliability, emissions/noise, cyber, privacy, approvals, value |
| Embodiment | actual removal/installation/fabrication, material lots, tools/machines, process parameters, workers, deviations and as-built evidence |
| Tuning/calibration | parameter schema, baseline, changed values/maps, protected limits, target compatibility, dyno/simulation/field evidence and rollback artifact |
| Verification | inspection, NDT, dimensional checks, functional test, dyno, software diagnostics, acceptance criteria and anomalies |
| Release | approval basis, limitations, maintenance instructions, competition/warranty/insurance impact, new configuration and public disclosure |
| Reversal | new work and configuration that reverses effects; original history remains and full reversibility is never assumed |

### 21.8 Software, calibration, and AI deployment

| Area | Required record |
| --- | --- |
| Artifact identity | kind, supplier/author, version claim, exact digest, signature, package IDs, license and release notes |
| Build provenance | source revisions, builder/toolchain, dependencies/lockfiles, feature flags, environment, tests and attestation |
| Compatibility | target controller/item, partition, hardware/design revision, operating system, interfaces and effectivity |
| Deployment | installer, method, previous artifact, active/standby state, secure boot, anti-rollback, activation and post-install test |
| Calibration | parameter schema/values, units, target, author/tool, as-found/as-left, protected limits, evidence and approval |
| AI model | purpose, authority class, runtime, input/output schemas, training provenance claims, evaluation, ODD, limitations and monitoring |
| Rollback | known-good artifact, compatibility, trigger, state migration, evidence and incident linkage |

```text
Authority class is structural
A vehicle persona, diagnostic assistant and steering controller may all use AI models, but their allowed output ports, grants, evidence and safety partitions differ. Sharing a model/runtime concept never grants the social plane access to a physical-control interface.
```

### 21.9 Restoration, repurpose, salvage, and retirement

| Disposition | Required distinction |
| --- | --- |
| Preservation / conservation | Arrest deterioration and stabilize historic material without inventing original state |
| Repair / restoration | Restore function or a documented earlier state; mark and document replacement/reproduction parts |
| Reconstruction / replica / recreation | Create missing or representative material under a new or explicit continuity relationship |
| Restomod / rebuild | Combine historic continuity with deliberate modern change; disclose removed/retained substance and identity policy |
| Repurpose / second life | Same component/asset can gain a new duty, configuration, approvals and responsible operator |
| Part harvest | Donor, removal, as-removed condition, traceability, inspection, reuse eligibility and new custody |
| Unsalvageable disposition | Quarantine, permanent service ineligibility, mutilation or controlled research/display use |
| Recycle / destroy / consume / lose | Material outputs, hazardous inventory, facility, certificates, retained evidence and identity disposition |

# 22. Telemetry, media, tests, dyno, simulation, condition, and evidence quality

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.22 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:3e3ca6ac5e4485eafae7e966b5cb157b30b486e2c786c902562b481db18828ac

Telemetry is not a collection of unlabeled numbers, and a photograph is not self-explanatory truth. Every dataset needs a manifest connecting channels, clocks, instruments, calibration, configuration, operation, rights and quality. Tests and derived metrics need procedures, acceptance criteria and reproducible processing. High-volume bytes live in immutable artifact storage; the lifecycle ledger stores their meaning and custody.

### 22.1 Telemetry segment manifest

| Manifest area | Required fields |
| --- | --- |
| Scope | asset/assembly, exact configuration(s), operation/segment, mode, control regime and location/privacy context |
| Source | device/controller/logger, hardware/software/firmware, sensor instances, calibration and capture authority |
| Time | start/end, phenomenon/result time, clock, timezone, synchronization method, drift, precision and producer sequence |
| Channels | stable signal ID, observed property, feature of interest, datatype, quantity kind, unit, frame, sign convention and null semantics |
| Sampling | rate/schedule, trigger, anti-alias/filter, resampling/interpolation and event versus periodic behavior |
| Quality | validity, range, saturation, dropout, packet loss, out-of-order data, duplicates, clock gaps and anomaly summary |
| Artifact | encoding/container, compression, schema, byte count, digest, chunk index, storage locator and encryption |
| Policy | privacy class, precise-location treatment, retention, export, license, redaction and permitted derived uses |

### 22.2 Channel descriptor and signal adapters

- A channel refers to a phenomenon/quantity and feature of interest, not only a bus address or column label.

- Preserve the native signal name, source namespace, datatype, unit, enum/version and scaling before mapping to a shared concept.

- COVESA VSS can be a road-vehicle signal adapter; it is not the universal tree for vessels, aircraft, robots, blimps or spacecraft.

- Map sensors, observation procedures, observed properties, result time and actuations through SOSA/SSN-compatible semantics where useful.

- Do not publish a value when its native source marks it unavailable; preserve unavailable, not-measured and unsupported separately.

- The same physical property from two sensors remains two observations until a declared fusion method derives a new estimate.

### 22.3 EvidenceArtifact and media provenance

| Area | Required semantics |
| --- | --- |
| Identity/integrity | artifact ID, media type, byte length, digest, encoding, storage, encryption and availability state |
| Capture | captured time/precision, device, actor, location/frame, operation/configuration and source clock |
| Custody | transfer, import, copy/derivative, verification, access, loss, destruction and retention events |
| Edit lineage | parent artifacts, editor/tool, transformations, crops/redactions, transcoding and output digest |
| Synthetic disclosure | none, assisted, partially synthetic or fully synthetic; generator/model/prompt/seed where policy permits |
| Rights | copyright, likeness, vehicle livery/franchise, license, purpose, territory, term and redistribution/model-training rights |
| Privacy | people, plates, exact location, private property, interiors, documents, audio/voice and redaction policy |
| Evidence role | supports which bounded proposition, direct/indirect/illustrative role and limitations |

```text
Content credentials are provenance, not truth
A valid content credential can show binding, signer and edit lineage; it does not prove that the depicted event happened or that the caption is accurate. A synthetic image can still be valuable creative media when clearly disclosed and isolated from factual maintenance, incident and registry evidence.
```

### 22.4 TestDefinition and TestRun

| Definition layer | Run layer |
| --- | --- |
| Purpose, requirement and acceptance criteria | Actual test article(s), configuration, state and deviations |
| Procedure/revision and applicability | Start/end, operator, facility, permissions and incidents |
| Apparatus, sensors, channel schema and calibration | Exact equipment/sensor instances, calibration status and setup evidence |
| Environment, load and preconditions | Observed environment, load, fuel/energy batch, payload and resource state |
| Excitation/profile, sampling and abort criteria | Commands/excitation, sequence, anomalies, aborts and excluded intervals |
| Uncertainty budget and processing plan | Raw artifacts, pipeline version, transformations, corrections and uncertainty |
| Evidence and reviewer requirements | Results, pass/fail/partial/invalid, reviewer, approvals, limitations and retest links |

### 22.5 Dyno and performance comparability

| Area | Required context |
| --- | --- |
| Machine + measurement location | engine/motor bench, crank/shaft, chassis roller, hub, wheel, propeller shaft, thrust stand, hydraulic/tool bench |
| Load device | inertia, eddy-current, water brake, electrical machine, aerodynamic/hydrodynamic load or other controlled sink |
| Configuration | engine/motor, gearing, tires/pressure/temperature, propeller/rotor, controller, calibration, exhaust/intake and restraints |
| Resource state | fuel/material batch, battery SOC/SOH/temperature, voltage, cooling, lubricants and ambient supply |
| Reference/correction | environment, correction method/standard, smoothing/filter, drivetrain-loss method and run-rejection rule |
| Raw + derived | time-series channels, curves, peak/average/integral metrics, formulas, uncertainty and processing version |
| Disposition | valid/invalid/partial/aborted, anomalies, acceptance, repeatability and comparability group |

- Never compare crank power with wheel power as equivalent.

- Never compare corrected and uncorrected values without the exact correction basis.

- Never hide smoothing, run rejection, gearing, tire, loss-estimation, battery or environment differences.

- A headline peak retains the run, curve, measurement location, configuration and uncertainty that created it.

### 22.6 Derived metrics, simulation, and digital-twin evidence

| Artifact | Must retain |
| --- | --- |
| Derived metric | input records/artifacts, formula/model, implementation digest, parameters, exclusions, units, uncertainty and execution receipt |
| Simulation model | purpose, fidelity, assumptions, equations/solver, geometry/configuration, material/aero/hydro data, boundary/initial conditions and validation |
| Simulation run | model version, exact inputs, compute environment, random seeds, convergence/error, outputs, anomalies and reviewer |
| Digital twin projection | physical source asset, synchronization authority, data cutoff, state estimator/model versions, latency and unresolved divergence |
| AI inference | model/runtime, input schema and records, output schema, confidence calibration, operating domain, human review and prohibited uses |
| Comparison set | compatibility criteria, normalization, exclusions, sample size, selection policy and information-loss warning |

### 22.7 Condition, defect, damage, failure, cause, and repair

| Object | Required distinction |
| --- | --- |
| Condition observation | Measured/observed property, target, method, result, uncertainty, time, configuration and evidence |
| Defect / nonconformance | Requirement violated or abnormal state, location, severity, status, operational effect and disposition |
| Damage | Type, geometry/location/frame, extent, initiating event, progression, allowable limit and scans/NDT |
| Failure event | Function lost/degraded/unintended, time, item/configuration, symptoms, effects, detection, shutdown and recovery |
| Causal assertion | Candidate cause/mechanism, contributing factors, method, evidence, confidence, alternatives and dispute state |
| Repair definition | Applicability, geometry/material/process, strength/performance basis, inspection, life limit and approval |
| Repair execution | Actual damage, preparation, removed material, repair feature/lots, process/cure, deviations, measurements, NDT and release |

```text
Cause never overwrites observation
A crack, fault code or power loss is an observation/event. Root-cause analysis is a separate, revisable assertion with competing hypotheses. Repair can restore function but never erases the damage, failure or evidence history.
```

### 22.8 Health, remaining life, and readiness projections

- Health, wear, remaining useful life, readiness and predicted due date are derived projections with algorithm/model version, input meters/condition, uncertainty and as-of time.

- Separate component, system, mission and fleet readiness. One degraded camera need not make a truck immobile; one failed brake may make it unavailable for road operation.

- Separate detected fault, diagnosed cause, deferred defect, operational limitation, maintenance due and release-to-service status.

- A projection can change when new evidence arrives without rewriting the original telemetry, inspection or work records.

- Public profiles should expose friendly summaries while owner/technician views preserve the exact evidence and conflicts behind them.

# 23. Vehicle-native social agent, rights, community, valuation, and commerce

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.23 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:53df8c9ee650cf0f5748134eea1b1b2820cd156d3e64dee37cc3c40877c9a801

The vehicle is the account, but the vehicle is not presumed to be a legal person or owner of unlimited authority. A governed vehicle agent can observe consented signals, retrieve lifecycle evidence, create a recognizable personality, draft disclosed media, converse with followers and perform specifically authorized digital actions. The owner, keeper, team, rights holders and service providers remain explicit principals and beneficiaries.

```text
Agent boundary
Persona gives the vehicle a voice; evidence gives the voice factual grounding; grants give the agent bounded authority. None of those creates physical-control, spending, sale, title, likeness or franchise rights unless a separate current grant explicitly does so.
```

### 23.1 Persona and vehicle-agent objects

| Object / area | Required content |
| --- | --- |
| Persona | Name, voice, visual identity, character traits, canon, backstory, language, humor, boundaries and version history |
| Represented asset set | One vehicle, assembly, fleet, model line or event character with explicit relationship and continuity |
| Knowledge projection | Allowed evidence, truth lanes, privacy policy, as-of time, source-precedence and conflict exposure |
| Interaction policy | Who may converse, topics, moderation, age/location constraints, escalation and rate limits |
| Publishing policy | Draft/approval/autopublish mode, platforms, disclosure, correction, schedule and location delay |
| Action skills | Event search, ticket help, training, merch, booking, invitations, service reminders and other scoped integrations |
| Commercial grants | Budget, price/discount bounds, settlement, revenue destination, approvals and accounting |
| Physical-control boundary | Explicitly null for the social-media plane; separate networks, credentials, APIs and safety ownership |
| Rights bundle | Vehicle likeness, logos/livery, media, human likeness/voice, persona, franchise/canon, music and territory/platform terms |
| Succession | What happens on ownership transfer, persona retirement, rebrand, rebuild, destruction, replica or host transfer |

### 23.2 Grounded content record

| Stage | Receipt |
| --- | --- |
| Observe / retrieve | Input record IDs, telemetry/media manifests, exact projection, conflicts and unavailable evidence |
| Plan | Audience, goal, story type, factual claims, creative treatment, sensitive topics and rights checks |
| Generate | Agent/persona/model version, prompt/brief, source coverage, unsupported statements removed and creative portions |
| Review | Automated policy checks, human approval/edit, factual source links, synthetic disclosure and privacy redaction |
| Publish | Platform/account, publishing grant, canonical artifact, time, location delay, rights basis and platform receipt |
| Engage | Conversation context, moderation, factual grounding, actions proposed and escalation |
| Correct / retract | Original publication, reason, corrected claim/artifact, audience notification and retained history |
| Measure | Reach/engagement/conversion with privacy, attribution method, time window and no claim of intrinsic truth/value |

A post may mix lanes: a factual telemetry sentence cites observed data; an owner memory is asserted; an efficiency estimate is derived; a Transformers-like voice line is creative. Each sentence or content block can carry its lane and citations so a compelling character never muddies the engineering record.

### 23.3 Rights and authority matrix

| Rights family | Distinct scopes |
| --- | --- |
| Physical asset | own, possess, lease, lien, custody, transport, operate, maintain, modify, inspect, scrap |
| Data | collect, access, localize, analyze, combine, export, retain, delete, license and train models |
| Location | live, delayed, historical, coarse, venue-only, private-route and emergency disclosure |
| Media | capture, edit, publish, sublicense, archive, monetize, use for training and create derivatives |
| Human rights | likeness, voice, personal data, passenger/crew privacy, consent or other lawful basis and withdrawal |
| Vehicle character | name, persona, voice model, canon, account, followers, appearance, livery and transfer |
| Brand / franchise | marks, designs, characters, music, territory, media, term, approvals and quality control |
| Social action | draft, post, reply, follow, invite, message, moderate and correct |
| Commerce | quote, discount, book, buy, list, accept offer, bid, auction, sell, invoice, collect and refund |
| Delegation | which agent/team may receive which subset, for what purpose, period, territory, budget and subdelegation |

```text
Transfer is not a bundle shortcut
Selling the truck does not automatically transfer private telemetry, old-owner likeness, copyrighted photos, a franchise license, its persona voice, followers, outstanding bids, publishing grant or revenue split. Each relation has an explicit succession, revocation and disclosure policy.
```

### 23.4 Spotting and invitation workflow

1. Capture only what is lawful and appropriate in the place; preserve raw evidence privately when needed.

1. Resolve the vehicle cautiously from visible features and identifiers; a plate, VIN, logo or image similarity never auto-merges an identity.

1. Create a spotting claim with time/location precision, confidence, media rights, people/plate privacy and no ownership assertion.

1. Offer a physical card, QR envelope or event invitation that lets the owner/keeper claim or dispute the candidate profile.

1. Verify control of the vehicle/profile through evidence appropriate to the risk, without publishing private identity documents.

1. Interview the person or team about the vehicle story; store their memories as attributed assertions and approve public excerpts.

1. Create redacted public media and a delayed/coarsened location projection; never expose home, storage or live route by default.

1. Use the resulting interests only for consented, purpose-bound event, service or partner recommendations.

### 23.5 Market objects must remain distinct

| Object | Meaning |
| --- | --- |
| Appraisal | Analytical estimate under a method, date, configuration, condition, assumptions and uncertainty |
| Price indication | Informational provider signal; may be stale, non-binding or source-specific |
| Listing | Seller/agent invitation describing asset, terms, disclosures and sale authority |
| Standing offer | Continuously visible proposed price/terms from an eligible party, revocable under policy |
| Bid | Immutable auction participation under bidder eligibility, currency, amount, time and auction rules |
| Auction | Governed mechanism with opening/closing, reserve, increments, anti-sniping, pause/cancel and settlement |
| Transaction | Accepted terms, parties, authority, title/custody, payment/escrow, delivery, taxes/fees and receipts |
| Revenue event | Service/content/booking/sponsorship/merch income, allocation, beneficiary, platform fee, tax and payout |

```text
No generic price field
Current bid, reserve, asking price, latest sale, appraised value, insured value, replacement cost and owner sentiment are different records. Followers, media reach and story quality can be valuation inputs under an explicit model; they are never provenance or proof of market value by themselves.
```

### 23.6 Auction state and bid projection

| State | Required behavior |
| --- | --- |
| Draft | Subject resolution, configuration/condition dossier, seller authority, disclosures, jurisdiction, currency and policies |
| Scheduled | Immutable announced rules, opening/closing times, reserve/increment, bidder eligibility and settlement route |
| Open | Accept immutable eligible bids; trusted time, anti-sybil/rate controls and public privacy projection |
| Paused | Reason, authority, bidder notice, clock treatment and permitted resume/cancel behavior |
| Closed | Apply eligibility, timing, reserve, anti-sniping and tie policies to produce a result projection |
| Settling | Identity/title/lien checks, payment/escrow, inspection, contract, taxes/fees, delivery and approvals |
| Settled / failed | Final transaction/receipts or reason for failure, refunds, dispute and relisting policy |

The public current bid is a deterministic projection over eligible, timely, non-retracted bids under the exact auction-policy version. The bid ledger is not edited when the leader changes. A live standing offer outside an auction uses a separate Offer contract.

### 23.7 Action proposal, grant, and receipt

| Record | Required content |
| --- | --- |
| Proposal | agent, requested action, subject/resources, purpose, inputs, expected effect, cost/risk and expiry |
| Policy evaluation | candidate grants, prohibitions, duties, audience, budget/rate, confirmation and conflicts |
| Authorization | grantor, grantee, exact scope, conditions, configuration/domain/time and revocation epoch |
| Confirmation | human or designated controller approval for high-impact spending, sale, publication or booking |
| Execution | integration/tool, exact request, idempotency, start/end, external transaction reference and errors |
| Receipt | grant used, inputs, result, money/rights/location effects, artifacts, failure/rollback and reconciliation |
| Outcome appraisal | Did the action achieve the intended result, under which measure, reviewer and evidence? |

### 23.8 Revenue and community services

- event discovery, invitations, ticket/seat assistance, training sessions, track days, club membership and venue concierge

- maintenance, parts, detailing, charging/fueling, storage, transport, insurance and specialist provider recommendations

- media packages, sponsorship, licensed character collaborations, merchandise, appearances, tours and vehicle-led channels

- race data, coaching, simulation, challenges, skill credentials, internships, portfolio evidence and human-reviewed recruitment pathways

- booking, rental, Turo-like access, robotaxi/eVTOL service, demonstrations and mission assignments under separate operating authority

- appraisal, listing, standing offers, auction, financing/escrow referrals and verified lifecycle dossier export

Recommendations should be relevant because the vehicle's configuration, condition, location policy, events and owner preferences are known - not because private telemetry is silently sold. Commercial targeting remains purpose-bound, explainable and revocable.

# 24. Machine contracts, standards profiles, security, conformance, and governance

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.24 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:b39146697903e318e3d096b78c43be42ba5e6fc0737a90af15b57d8e4550e256

Universality depends on a small kernel and strict extension rules. Standards are pinned profiles and adapters, not the root ontology. The compact JSON wire form is checked structurally, expanded through immutable semantic contexts, validated across graph relationships, and then admitted to an append-only ledger. Unknown namespaced data must survive even when the current client cannot interpret it.

### 24.1 Standards adoption profile

| Standard/profile | Bounded RTracer use |
| --- | --- |
| JSON Schema 2020-12 | Wire structure and payload validation; kernel objects closed, typed extension array open |
| JSON-LD 1.1 | Stable IRIs and semantic export using locally pinned context bytes/digests |
| SHACL | Cross-object cardinality, graph, temporal, type and pack constraints |
| SKOS / limited OWL | Vocabulary concepts, labels, hierarchy, mappings and design-time axioms; never authorization |
| PROV-O | Entities, activities, agents, derivation, revision, attribution and custody mappings |
| SOSA/SSN + OGC SensorThings | Observation/actuation semantics and geospatial IoT API adapters |
| QUDT / UCUM + uncertainty profile | Quantity kinds, dimensions, units and uncertainty exchange |
| COVESA VSS; ASAM MDF/ODS/OpenODD | Road signals, measurement/test data and road ODD adapters |
| GS1 EPCIS | Supply, lot, aggregation, transformation, custody and traceability event mapping |
| ODRL / Verifiable Credentials | Rights-expression and signed-assertion exchange; internal grants remain stricter |
| C2PA | Media provenance, edit lineage and synthetic-disclosure signals; no automatic truth claim |
| CloudEvents / OpenAPI / OpenTelemetry | Transport, HTTP contract and platform observability; none replaces domain history |
| RFC 3339 / JCS profile | Timestamp representation and deterministic canonical JSON hashing/signing |
| UNECE R155/R156 / firmware-update profiles | Cybersecurity and software-update-management adapters for applicable road vehicles |
| EU battery passport | Individual battery identity, use/state/repurpose history, access control and interoperable passport adapter |

```text
Pin, do not follow latest
Every schema, context, shape, ontology, vocabulary and standard mapping is stored by exact version and digest. Production validation never fetches remote contexts or schema references. A moving URL cannot silently change the meaning of historical records.
```

### 24.2 Canonical v1 contract families

- core.entity-root/v1; core.record-envelope/v1; core.temporal-extent/v1

- identity.identifier-assertion/v1; identity.continuity-decision/v1; identity.conflict-set/v1

- claims.claim/v1; claims.appraisal/v1; evidence.artifact/v1; evidence.custody-event/v1

- configuration.snapshot/v1; configuration.operational-state/v1; systems.graph/v1; systems.connection/v1

- capability.realization/v1; control.authority-assignment/v1; control.handover/v1

- operation.mission/v1; operation.session/v1; operation.segment/v1

- lifecycle.task-definition/v1; lifecycle.task-execution/v1; lifecycle.modification/v1; lifecycle.finding/v1

- measurement.quantity/v1; measurement.test-run/v1; telemetry.segment-manifest/v1

- rights.grant/v1; action.proposal/v1; action.receipt/v1; social.vehicle-agent/v1

- commerce.appraisal/v1; commerce.listing/v1; commerce.offer/v1; commerce.bid/v1; commerce.auction/v1; commerce.transaction/v1

- registry.provider-assertion/v1; vocabulary.term/v1; schema.definition/v1; extension.domain-pack/v1

### 24.3 Three validation representations

| Layer | Purpose | Hard rules |
| --- | --- | --- |
| A - JSON Schema | Validate compact wire object | Reject duplicate keys, NaN/infinity/negative zero, unbounded depth/arrays, unknown kernel keys and untrusted refs |
| B - JSON-LD | Expand namespaced semantics | Pinned local context only; digest verified; no network fetch or context substitution |
| C - SHACL / graph rules | Validate relationships and packs | Cardinality, subject/object types, graph cycles, time/effectivity, port compatibility, authority prerequisites and pack dependencies |
| D - policy engine | Decide audience/action permission | Current grant, purpose, privacy, jurisdiction, budget/rate, revocation and no ontology-inferred authority |

JSON numeric values are unsuitable where exact decimals matter. Preserve exact lexical decimal strings and validate their grammar. Canonicalization rejects ambiguous representations before hashing. Extensions use {namespace, schemaRef, payload, originalDigest}; arbitrary extra fields are not the extension mechanism.

### 24.4 DomainPack manifest

```text
Signed domain-pack manifest
{
  "packId": "rtracer.domain.aerostat",
  "version": "1.2.0",
  "coreCompatibility": ">=1.0 <2.0",
  "dependencies": [{"packId": "rtracer.domain.air", "version": "2.1.0"}],
  "vocabularies": ["sha256:..."],
  "schemas": ["sha256:..."],
  "contexts": ["sha256:..."],
  "shapes": ["sha256:..."],
  "mappings": ["sha256:..."],
  "migrations": ["sha256:..."],
  "fixtures": ["sha256:..."],
  "privacyProfile": "rtracer.privacy.vehicle/v1",
  "license": "SPDX-expression-or-private-policy-ref",
  "publisherRef": "party:rtracer-pack-council",
  "manifestDigest": "sha256:...",
  "signatureRef": "proof:..."
}
```

- Packs can add namespaced terms, schemas, constraints, forms, projections and adapters; they cannot redefine identity, time, evidence, rights or append-only semantics.

- Dependencies are deterministic, acyclic and locked per configuration/export. Conflicts fail explicitly.

- Manufacturer, club, regulator and tenant packs may remain private while mapping to shared concepts.

- Bridge packs compose road+marine, air+space, RC+competition or mobile-base+tool semantics without copying either parent.

- Unknown pack payloads and terms must round-trip byte-for-byte with their schema/digest metadata.

### 24.5 API surface and write discipline

| Surface | Contract |
| --- | --- |
| POST /records | Append typed record with mandatory Idempotency-Key; same key/different bytes is equivocation |
| GET /entities/{id}/timeline | Bitemporal validAt/knownAt history with policy-filtered claims and conflicts |
| GET /configurations/{id} | Immutable graph, pack lock, digest and predecessor/diff |
| GET /entities/{id}/graphs | Typed system/relationship traversal by kind, configuration and as-of time |
| POST /identity-resolution/candidates | Candidate set and evidence; never an automatic merge |
| POST /actions/proposals | Create inert proposal; policy evaluation and confirmation are separate |
| POST /actions/{id}/authorizations | Append scoped grant/approval evaluation |
| POST /actions/{id}/receipts | Append execution and outcome evidence |
| POST /imports and /exports | Preserve source artifact, license, mappings, loss manifest, pack lock and receipt |
| GET /schemas, /vocabularies, /packs | Content-addressed registry retrieval without runtime remote resolution |
| GET /event-stream | Policy-filtered events; transport envelope never replaces canonical record |

### 24.6 Security threat model

| Threat | Required control |
| --- | --- |
| VIN/serial/MAC cloning | Opaque root identity; identifier conflicts; never authenticate or merge from an external identifier |
| Telemetry spoof/replay | Device identity, producer sequence, nonce/window, digest, calibration, clock quality and anomaly appraisal |
| Social agent reaches controls | Separate networks, credentials, API namespaces and grants; physical-control grant null by construction |
| Prompt injection in uploads | All external text/media/telemetry inert; fixed skills; no command execution from content |
| Malicious domain pack | Signed digest, namespace isolation, local review, constrained validators, dependency and fixture checks |
| Schema/context SSRF | Offline pinned registries; remote resolution disabled; size and recursion limits |
| Canonicalization ambiguity | Reject duplicate keys, invalid Unicode/numbers and representation equivocation before signing |
| Ledger/idempotency equivocation | Same ID/key with different canonical bytes quarantined and alerted |
| Cross-tenant/location inference | Field/edge policy, delay/coarsening, non-leaking errors and aggregation review |
| Privilege persists after transfer | Epoch-based grants revoked/reissued on ownership, custody, team or persona change |
| Maintenance/odometer fraud | Conflicting claims retained, source/custody evidence, meter lineage and appraisal policy |
| Auction manipulation | Immutable bids, trusted time, eligibility, anti-sybil/rate controls and settlement receipts |
| Synthetic-media laundering | Truth-lane enforcement, edit lineage, content credentials where available and disclosure |
| Parser/archive/telemetry DoS | Byte/depth/count/decompression limits, quotas and separate high-volume ingestion |
| Update/supply-chain attack | Signed artifact, build/dependency provenance, target compatibility, secure activation and rollback |
| Confidential data in logs | Opaque IDs, structured redaction, no VIN/name/location/prompt/telemetry labels |

### 24.7 Cumulative conformance levels

| Level | Capability | Exit proof |
| --- | --- | --- |
| L0 Preserve | Store/export unknown signed records and namespaced extensions | Byte/semantic round trip with no coercion |
| L1 Kernel | Entity, record, bitemporal claims, evidence, identifiers and deterministic replay | Conflict and correction fixtures pass |
| L2 Lifecycle | Configuration, components, graphs, maintenance, modification, continuity and role relationships | As-operated history reconstructs |
| L3 Measurement | Quantities, uncertainty, calibration, telemetry manifests, time sync and test evidence | Raw-to-derived lineage reproduces |
| L4 Governed agent | Privacy projections, persona, grounded content, grants and receipts | No unsupported factual post or physical path |
| L5 Market/registry | Appraisal, listing, offers, bids, auction, transaction and licensed adapters | Authority, eligibility and settlement fixtures pass |

Conformance is cumulative; domain-pack badges are orthogonal, such as L3 + marine, L4 + RC/model or L5 + EU-road. Physical-control safety certification is never implied by an RTracer level.

### 24.8 Migration and release protocol

1. Publish the immutable target schema, context, shapes, vocabulary and pack manifest with digests/signatures.

1. Classify compatibility and publish deterministic upcaster, optional downcaster and explicit information-loss manifest.

1. Run positive, negative, adversarial, round-trip and corpus fixtures; lock migration implementation digest.

1. Deploy read-time adapters and build a shadow projection from original records.

1. Compare old/new projections, conflicts, privacy and performance; resolve divergence before new writes.

1. Activate the new write version while retaining old readers for the declared support window.

1. Issue migration receipts; never rewrite original record bytes or silently relabel historical terms.

1. Deprecate identifiers with replacement mappings; keep retired definitions resolvable forever.

### 24.9 Operational observability

| Area | Metrics / alerts |
| --- | --- |
| Ingestion | latency, schema/shape failures, missing refs, digest/signature failures, idempotency conflicts and quarantine |
| Semantics | unknown terms, mapping loss, conflict-set growth, pack resolution and projection divergence |
| Telemetry/evidence | dropout, clock drift, chunk collision, artifact digest failure, calibration expiry and storage loss |
| Privacy/rights | permission denials, redaction failures, location-policy tests, expired grants and transfer revocation |
| Agent | source coverage, creative disclosure, human edit/approval, correction rate and proposal-to-receipt completion |
| Market | bid rejection, eligibility, close-time, reserve, settlement mismatch, refunds and disputes |
| Migration | shadow mismatch, up/downcast loss, replay determinism and unknown-extension round trip |

### 24.10 Explicit non-goals

- one final taxonomy or inheritance tree for every vehicle

- replacement of government registries, licensed history providers, certification bodies or legal title systems

- automatic truth from signatures, confidence, popularity, AI output or a single provider

- identity inference from VIN, serial, MAC, token, plate or image similarity alone

- real-time safety-critical control bus or cross-domain autonomy certification

- raw telemetry in the semantic graph or precise public location by default

- automatic transfer of persona, voice, followers, private data, franchise, media or sale authority with ownership

- ontology inference as authorization or arbitrary tool execution from persona-generated text

- blockchain, token or decentralized-ID dependency in the kernel

- guaranteed lossless mapping of every proprietary, local or future scheme

- treating people or animals as components, property or unconsented telemetry payloads

# 25. Normative implementation profile and primitive contracts

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.25 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:c8062e44851501611dcd8947cd834d818982e3d44e138b6689829c9e1c7672e0

v1.4 precedence: Standard 1.4 does not relabel or redigest RecordCore 1.3. Exact v1.4 operational profiles in Sections 33–44, Section 55, and Appendices N–Q supersede conflicting illustrative persistence, proof, receipt, event, cursor, control, and command shapes. Appendix D MUST be read through the v1.4 profile and MUST NOT define an alternative contract.

Sections 1–24 define what the substrate means. Sections 25–32 define how a conforming implementation writes, validates, stores, replays and serves that meaning. The contract is technology-neutral but not behavior-neutral: two implementations may choose different databases or programming languages only if canonical bytes, validation outcomes, temporal answers, authorization decisions and receipts remain interoperable.

```text
Normative language
MUST and MUST NOT are conformance requirements. SHOULD identifies a strong default whose deviation requires a recorded rationale. MAY identifies an optional behavior whose presence cannot weaken a MUST. Examples are non-normative unless a fixture says otherwise.
```

### 25.1 Contract layers

| Layer | Owns | Must never own |
| --- | --- | --- |
| Semantic kernel | Identity, typed records, time, provenance, correction, evidence, grants and receipts | UI labels, database joins, vendor identifiers or inferred authorization |
| Wire profile | Canonical JSON object shape, exact scalar grammar, media type and digest input | Domain truth beyond the referenced schema and vocabulary lock |
| Graph profile | Subject/object typing, topology, effectivity, cardinality and cross-record invariants | Physical control execution or policy decisions |
| Policy profile | Current principal, action, resource, purpose, audience, context, duties and revocation | Rewriting records or treating ontology inference as permission |
| Persistence profile | Atomic append, idempotency, ordering, outbox and rebuild checkpoints | Product semantics hidden in database triggers |
| Projection profile | Deterministic, versioned read models for a declared audience and as-of time | Authoritative mutation or silent conflict resolution |
| Transport profile | HTTP/event framing, authentication, rate limits, correlation and retry contract | Replacing the canonical record envelope |

### 25.2 Primitive scalar profile

| Primitive | Canonical form | Forbidden shortcut |
| --- | --- | --- |
| OpaqueId | lowercase UUID textual form or equivalent 128-bit opaque value | Never contains VIN, serial, tenant, time-zone or vehicle class semantics |
| TermRef | absolute namespaced identifier plus vocabulary version/digest | Human label is presentation metadata, not the stored term |
| SchemaRef | immutable schema identifier, semantic version and content digest | A mutable latest URL is not valid for historical records |
| Timestamp | UTC instant with explicit offset and bounded fractional precision | Leap/clock uncertainty recorded separately; no local time without zone |
| TimeInterval | half-open [start, end) with open end allowed | End precedes start; adjacent intervals do not overlap |
| DecimalString | canonical sign, digits, optional fraction; scale declared by schema | Binary floating-point for money, exact quantity or digest input |
| IntegerString | canonical base-10 integer when range exceeds safe JSON integer | Leading plus or ambiguous leading zeros |
| Money | currency term, exact amount, minor-unit policy and rounding context | Generic price field or currency inference from locale |
| QuantityValue | quantity kind, original value/unit, optional canonical value/unit and uncertainty | Unitless numeric value unless the quantity kind is dimensionless |
| Digest | algorithm identifier plus lowercase encoded digest bytes | Digest alone as proof of identity, truth or authority |
| LanguageString | text, BCP-47 language tag and optional direction | Machine translation overwriting the source string |
| GeoValue | coordinate reference system, axes/order, datum, epoch, uncertainty and privacy class | Bare latitude/longitude pair with assumed frame |

### 25.3 Presence and knowledge states

Omission is reserved for a field that is inapplicable to the selected schema branch. A field whose value is relevant but unknown must carry an explicit knowledge state. This prevents missing telemetry, withheld ownership, unsupported adapters and zero-valued measurements from collapsing into null.

| State | Meaning | Projection rule |
| --- | --- | --- |
| known | A value is present and valid under the referenced schema | Return value subject to policy |
| unknown | The question is meaningful but no value is currently established | Return unknown; do not invent default |
| not_observed | Observation could have occurred but did not | Distinguish from sensor failure and zero |
| not_measured | A measurement procedure was not performed | Do not calculate from absent input unless a derivation says so |
| unavailable | Source or service could not provide a value | Expose availability state and retry/freshness metadata |
| withheld | Value exists but policy suppresses it | Return non-leaking withheld marker if audience may know that |
| redacted | Value was removed from this projection or export | Include redaction policy/receipt when allowed |
| disputed | Conflicting evidence remains unresolved | Return conflict set or declared policy choice with explanation |
| unsupported | Adapter or implementation cannot interpret the value | Preserve original bytes and schema reference |
| not_applicable | The question does not apply in this schema/context | Never treat as false, zero or unknown |

### 25.4 Canonical serialization and digest boundary

1. Reject malformed Unicode, duplicate object keys, non-finite numbers, negative zero and values outside schema limits before normalization.

1. Resolve the exact local schema and semantic context by immutable identifier and digest; runtime network resolution is disabled.

1. Normalize identifiers, timestamps, decimal lexical forms, term references and unordered-set fields according to the selected schema version.

1. Sort object member names according to the canonical JSON profile; preserve array order unless the schema explicitly declares set semantics and a canonical key.

1. Encode canonical UTF-8 bytes with no insignificant whitespace and compute recordDigest over the canonical record body, excluding transport headers and mutable signature containers.

1. Bind signatures to the digest, schema lock, signer identity, signing purpose, algorithm suite, creation/expiry and key epoch.

1. Store original received bytes and media type when required for evidentiary or import fidelity; original bytes and canonical bytes are different artifacts.

```text
Hash equality is narrow
Equal canonical digests prove equal canonical bytes under one profile. They do not prove that two physical assets, claims, photographs or events are the same, true, lawful or authorized.
```

### 25.5 Compatibility classes

| Change | Compatibility | Required handling |
| --- | --- | --- |
| Add optional field with explicit default-absence semantics | backward compatible | New writer may emit; old reader preserves extension or ignores only if schema permits |
| Add required field | breaking | New major schema or deterministic upcast with supplied provenance |
| Narrow allowed value/range | breaking for existing data | Corpus scan, exception policy and migration receipt |
| Broaden allowed value/range | reader-forward risk | Declare minimum reader; fixtures for unsupported values |
| Rename term or field | semantic mapping | Stable old identifier, replacement relation and lossless transform |
| Change unit or numeric scale | potentially lossy | Exact conversion rule, rounding method and loss manifest |
| Change truth lane, authority or privacy meaning | never silent | New concept/schema; no aliasing across boundaries |
| Change canonicalization profile | digest-breaking | New profile ID; preserve old digests and dual verification |

# 26. Canonical record ledger, claims, evidence, and identity resolution

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.26 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:e3e7b46937d19dd45cdb8aa4642aa7bd9383b5765cd0810aee5e2bacac5597f1

The canonical ledger is not a mutable vehicle row. It is an ordered set of immutable typed records whose relationships allow a policy-bound view to be reconstructed for valid time and knowledge time. Record acceptance is a transaction: either the canonical record, subject links, digest, idempotency binding and outbox entry commit together, or none do.

![Diagram of the canonical RTracer write pipeline from strict receive and parse through normalization, validation, authorization, append, outbox publication and rebuildable projections.](/substrate/v1.4.1/assets/media/image8.png)

The append is authoritative; every downstream view is versioned and rebuildable.

### 26.1 Four records that must not collapse

| Object | Authority | Mutation rule |
| --- | --- | --- |
| RecordCore | Producer-authored semantic content, subjects, valid time and source context | Immutable; digest excludes proofs, transport and store metadata |
| ProofRecord | Signature/attestation over one exact RecordCore digest | Additional proofs may append without changing the core |
| IngestReceipt | Store acceptance decision, transaction time, validator/policy lock and log position | One or more custodians may issue receipts; producer cannot self-assert store time |
| ProjectionReceipt | Projector code/policy/registry versions, input watermarks and output digest | Rebuildable; never authoritative history |

```text
Integrity is not truth or authority
A valid proof establishes that a key signed particular bytes under a profile. It does not establish that the signer was authorized, the claim was accurate, the vehicle was owned, the configuration was safe or the event occurred.
```

### 26.2 RecordCore v1

```text
Canonical producer-authored RecordCore - illustrative JSON
{
  "recordId": "018f4d6e-7db2-7e40-9a13-7d7f12f00101",
  "recordType": "rtracer.claim.assertion/v1",
  "schemaRef": {"id": "schema:rtracer.claim.assertion/v1", "digest": "sha256:..."},
  "subjects": [{"entityId": "018f...aa", "role": "subject"}],
  "validTime": {"start": "2026-07-22T09:00:00Z", "end": null},
  "authoredAt": "2026-07-22T09:00:02.700Z",
  "producer": {"principalId": "018f...10", "systemId": "018f...11"},
  "tenantScope": "018f...01",
  "truthLane": "asserted",
  "visibilityPolicyRef": "policy:owner-team/v3",
  "body": {"predicate": "vehicle:paintColor", "object": {"term": "color:blue"}},
  "extensions": []
}
```

| Field group | Requirement |
| --- | --- |
| identity | recordId is opaque and immutable; recordType and schemaRef select exact semantics |
| subjects | one or more typed subject links; roles are schema-governed and order-independent unless declared |
| time | valid interval is application time; authoredAt is an issuer claim, not system transaction time |
| producer | human/device/service principal, producing system, tenant and delegation chain where relevant |
| epistemic | truth lane, knowledge state, confidence semantics, evidence coverage and verification state |
| policy | visibility policy, purpose restrictions, retention class and sensitive-field map |
| body | closed payload governed by recordType; extensions are explicit namespaced containers |
| integrity | canonical core digest is computed outside the core; proofs and store receipts reference ID plus digest |
| correction | supersedes/corrects/retracts/disputes/derivesFrom relations remain separate typed records |

```text
Store-authored IngestReceipt v1.4 - illustrative JSON
{
  "receiptProfile": "rtracer.ingest-receipt/1.4",
  "target": {"recordId": "018f...0101", "recordDigest": "sha256:..."},
  "decision": "accepted",
  "acceptedAt": "2026-07-22T09:00:03.184Z",
  "storeId": "018f...store",
  "ledgerId": "018f...ledger",
  "logicalShardId": "ledger-03",
  "chainEpoch": "1",
  "commitSequence": "982173",
  "streamId": "018f...stream",
  "streamSequence": "185",
  "validatorSetDigest": "sha256:...",
  "registrySnapshotDigest": "sha256:...",
  "authorizationDecisionRef": "record:policy-decision",
  "previousReceiptDigest": "sha256:...",
  "canonicalAdmissionEventId": "019b...event"
}
{
  "target": {"recordId": "018f...0101", "coreDigest": "sha256:..."},
  "decision": "accepted",
  "acceptedAt": "2026-07-22T09:00:03.184Z",
  "storeId": "018f...store",
  "partition": "tenant-01/ledger-03",
  "ledgerSequence": "982173",
  "validatorSetDigest": "sha256:...",
  "registrySnapshotDigest": "sha256:...",
  "authorizationDecisionRef": "record:policy-decision",
  "previousReceiptDigest": "sha256:..."
}
```

### 26.3 Minimal logical ledger tables

| Table | Primary key / indexes | Purpose |
| --- | --- | --- |
| entity_root | entity_id; tenant_id, created_seq | Durable opaque identity and coarse kind only |
| record_ledger | record_id; unique tenant+ledger_seq; record_type+recorded_at | Canonical bytes/digest, schema lock, valid time, producer and policy |
| record_subject | record_id+ordinal; index entity_id+valid_start | Typed subject/object participation without parsing payload |
| record_relation | source_record+relation+target_record | Correction, derivation, dispute, corroboration and custody graph |
| idempotency_binding | tenant+principal+key | Request digest, result record, status and expiry policy |
| evidence_artifact | artifact_id; digest+byte_length | Immutable object metadata, encryption, rights and storage locator |
| identifier_assertion | record_id; namespace+normalized_value | Attributed external identifier claim and conflict lookup |
| outbox_event | logical_shard+chain_epoch+commit_sequence+event_kind | Atomic publication state, attempts, next retry and dead-letter reason |
| projection_checkpoint | projection_id+tenant+logical_shard+chain_epoch | Last applied sequence, code/schema version, digest and rebuild state |
| quarantine_item | quarantine_id; received_at | Original bytes, failure stage, reason, reviewer and disposition |

The logical model does not require one relational product. It does require the uniqueness, atomicity and replay semantics shown above. Database-generated cascade updates and deletes are prohibited on canonical records.

### 26.4 Claim and evidence separation

| Object | Carries | Does not prove |
| --- | --- | --- |
| Observation | procedure, phenomenon, result, sensor/operator, time, configuration and quality | Cause, identity or fitness beyond its measured scope |
| Assertion | issuer, subject, predicate, object, scope, effective interval and authority context | Truth merely because signed or repeated |
| DerivedClaim | input record IDs, formula/model digest, parameters, output, uncertainty and execution receipt | Stronger authority than its method and inputs support |
| EvidenceArtifact | bytes/digest, capture, custody, rights, privacy, edit lineage and availability | That the depicted or encoded proposition occurred |
| Verification | checker, method, target claim/evidence, result, time, limitations and challenge path | Global truth outside the verification procedure |
| Decision | authorized decider, candidate claims, policy, rationale, effective scope and appeal | Erasure of competing historical evidence |

### 26.5 Identity resolution is a reviewable decision

1. Normalize each external identifier only within its issuer namespace and normalizer version; never globally.

1. Generate candidates from exact identifiers, known relationships, configuration evidence, provenance, geometry, media or temporal proximity.

1. Compute feature-level evidence contributions with direction, quality, independence and contradiction; do not expose one unexplained score as truth.

1. Apply hard exclusions such as overlapping exclusive custody, incompatible manufacturing provenance, impossible time/location or explicit split decisions.

1. Return candidate, conflict, insufficient-evidence or no-match. Automatic merge is forbidden for high-impact identity roots.

1. Require a signed continuity/merge/split decision with reviewer, policy version, evidence set, uncertainty, consequences and appeal/reversal path.

1. Represent an erroneous merge through superseding identity-resolution records; never rewrite the source entities or claims.

### 26.6 Bitemporal query contract

```text
Deterministic bitemporal projection - pseudocode
resolve(entityId, validAt, knownAt, projectionPolicy, schemaLock):
  records = ledger.records_for(entityId)
    .where(valid_time contains validAt)
    .where(recorded_at <= knownAt)
    .where(schema is interpretable under schemaLock)
  records = apply_corrections_as_known_at(records, knownAt)
  claimSets = group_by_proposition_and_scope(records)
  decisions = evaluate_trust_policy(claimSets, projectionPolicy)
  return Projection(value_or_conflict=decisions,
                    input_record_ids=all_inputs,
                    policy_digest=projectionPolicy.digest,
                    as_of={validAt, knownAt},
                    explanation=decision_receipts)
```

- validAt answers what applied in the world; knownAt answers what the system had accepted by then.

- A correction recorded today may change today's view of last year without altering what yesterday's users could have known.

- Projection responses include input record IDs, policy/schema versions, conflict disposition and checkpoint sequence.

- Pagination is bound to a stable ledger snapshot; page two cannot silently observe a newer state than page one.

# 27. Immutable configuration graph and capability compiler

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.27 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:ec1c822c3dc0699a736b321e8b26a7457f151e868e36730aeb0ec0884c0917ce

A configuration is a content-addressed declaration of installed occurrences, material state, software/calibration, ports, connections and controlled effectivity. It is neither the engineering design nor every millisecond of operating state. The capability compiler evaluates a configuration together with health, resources, environment, authority and mode; it never stores capability as an unqualified vehicle boolean.

### 27.1 ConfigurationSnapshot v1

```text
Immutable configuration snapshot - illustrative JSON
{
  "configurationId": "cfg:sha256:...",
  "assetId": "018f...aa",
  "predecessorIds": ["cfg:sha256:previous"],
  "creatingEventId": "record:modification-execution",
  "effective": {"start": "2026-07-22T10:00:00Z", "end": null},
  "packLock": [{"packId": "rtracer.domain.road", "version": "2.1.0", "digest": "sha256:..."}],
  "nodes": [{"occurrenceId": "occ:...", "definitionRef": "part:...", "identityRef": "entity:..."}],
  "edges": [{"kind": "installedAt", "from": "occ:...", "to": "slot:rear-axle", "effectivity": "true"}],
  "software": [{"artifactRef": "artifact:...", "targetController": "occ:ecu-1", "activationState": "active"}],
  "calibrations": [{"artifactRef": "artifact:...", "targetFeature": "feature:steering"}],
  "configurationDigest": "sha256:..."
}
```

### 27.2 Typed graph families

| Graph | Allowed cycles | Critical constraints |
| --- | --- | --- |
| physical composition | no | One node cannot contain itself; exclusive placements cannot overlap in valid time |
| structural/load path | only if mechanically meaningful and declared | Ports, direction, load cases, limits and test evidence compatible |
| energy/resource flow | yes | Typed form/carrier, direction, conversion, recovery and protection; no free-energy derivation |
| fluid/material flow | yes | Substance compatibility, pressure/temperature, containment and contamination constraints |
| data/communication | yes | Protocol/profile, trust zone, direction, bandwidth, latency, integrity and availability |
| control/command | yes with arbitration | Function scope, controller authority, feedback, safety partition and fallback |
| thermal | yes | Source/sink, conduction/convection/radiation relation, limits and operating state |
| kinematic/joint | yes for closed chains | Degrees of freedom, limits, frames, actuators, singularities and solver profile |
| functional dependency | yes | Dependency type, mode, minimum multiplicity, degraded alternatives and proof |
| temporary assembly/formation | no containment merge | Members retain identity; coupling, membership and command roles time-bounded |

### 27.3 Port compatibility contract

| Port family | Compatibility dimensions | Connection adds |
| --- | --- | --- |
| mechanical | geometry/mating profile, load axes, fastener/coupler, stiffness, clearance, environment | connection load envelope and inspection evidence |
| electrical power | voltage/frequency/phase/current, polarity, connector, isolation, grounding, fault level | protection coordination and energy direction |
| fluid | substance family, size, pressure, temperature, flow direction, seal/material compatibility | purity, leakage and contamination controls |
| data | physical/link/application profile, addressing, schema, bandwidth, latency, security and version | gateway transformations and loss manifest |
| control | command/feedback semantics, rate, authority, safe state, watchdog and arbitration | implementation lock and independent safety boundary |
| optical/RF/acoustic | band, power, aperture, modulation, field of view, timing and interference limits | jurisdiction, exposure and coexistence constraints |
| payload/tool | retention, pose/frame, loads, service ports, release method and hazard class | payload identity, mission grant and separation state |
| human/biological | fit, contact pressure, hygiene, accessibility, consent and emergency release | person remains principal/beneficiary, never component property |

### 27.4 Effectivity expression and three-valued evaluation

```text
Effectivity evaluator contract
applies(node_or_edge, context) -> TRUE | FALSE | UNKNOWN | ERROR

Expression := allOf | anyOf | not | compare | present | versionRange |
              timeRange | jurisdictionIn | modeIn | configurationHas |
              packTermMatches | quantityWithin | relationshipExists

Rules:
  UNKNOWN never authorizes, installs, removes or releases an item.
  ERROR quarantines the affected compilation path.
  Evaluation receipt binds expression digest, context record IDs,
  evaluator version, result and unresolved inputs.
```

### 27.5 Capability compilation

1. Select the exact configuration, operating mode, mission phase, domain/environment, location and valid/known time.

1. Match capability definitions whose structural, interface, software, calibration and pack requirements are realized.

1. Evaluate health, fault, maintenance, resource, payload, communication, weather and infrastructure preconditions.

1. Evaluate legal/organizational approval and function-scoped actor authority separately from physical availability.

1. Resolve mutually exclusive modes, dependencies, alternatives, degradations and arbitration constraints.

1. Emit designed, realized, available, authorized and engaged states independently with explanations and input IDs.

1. Cache only under the digest of configuration, context, compiler, policy, pack lock and source checkpoint; otherwise recompute.

```text
No giant capability bitset
A bitset cannot explain whether towing, hovering, autonomous docking, filming or bidding is possible for this configuration, actor, environment and moment. Capability results are derived records with a proof graph, not identity attributes.
```

### 27.6 Configuration diff and merge

| Operation | Required semantics | Invalid shortcut |
| --- | --- | --- |
| add occurrence | new occurrence ID, definition/instance identity, placement, ports, effectivity and evidence | Copying a part row without provenance |
| remove occurrence | removed occurrence, reason, disposition, meters/condition and effective time | Deleting it from history |
| replace | linked remove+add, equivalence/substitution basis, serial/lot transfer and tests | Mutating serial number in place |
| move/reorient | old/new placement and frame transform; evaluate connection/load changes | Changing coordinates without event |
| connect/disconnect | typed ports, compatibility result, procedure, checks and evidence | Implicit relation inferred from proximity |
| software/calibration | old/new artifact, target, activation, compatibility, approval, rollback and test | Editing a current-version string |
| material/consumable | quantity balance, batch/mixture provenance, location and resulting state | Treating fuel or paint as reusable component |
| branch/merge | multiple predecessor snapshots, conflict resolution, independent source histories | Last-write-wins snapshot merge |

# 28. Lifecycle transactions, maintenance scheduling, and accountable work

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.28 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:cb82dcbfd8869acb880d47ff8bf1aa9d0902194769116390581e0277b1b6a888

A maintenance note is not a lifecycle transaction. Every task has a definition, applicability decision, planned work package, execution, findings, material movements, measurements, release decision and resulting configuration or condition state. Care, wash, repair, modification, restoration, software deployment and decommissioning reuse this transaction spine while retaining their distinct intent and authority requirements.

### 28.1 Work package state machine

| State | Entry evidence | Permitted exits |
| --- | --- | --- |
| candidate | trigger, task definition, target and provisional due calculation | not-applicable, planned, deferred |
| planned | approved scope, applicability, prerequisites, resources, facility and schedule | released-to-work, superseded, cancelled |
| released-to-work | current configuration, permits, isolation, parts/tools/data and authorized performers | in-progress, suspended, cancelled |
| in-progress | start receipt, as-found capture and active custody | suspended, inspection-hold, completed-work, aborted |
| inspection-hold | finding, nonconformance or independent-inspection requirement | rework, concession, completed-work, rejected |
| completed-work | steps, actual parts/materials/software, measurements, deviations and as-left state | release-review, rework |
| release-review | required inspections/tests, open-item review, approvals and operating limitations | released, conditional-release, rejected |
| released | authorized release receipt and resulting configuration/condition | closed, reopened by new finding |
| closed | records complete, inventory/cost/waste reconciled and next-due initialized | superseding correction only |

### 28.2 Maintenance requirement and due engine

```text
Maintenance requirement and due projection
MaintenanceRequirement {
  requirementId, revision, authority, taskDefinitionRef,
  applicabilityExpression, initialThresholds[], repeatIntervals[],
  intervalBasis: calendar | distance | cycles | hours | launches |
                 landings | pressureEvents | energyThroughput |
                 componentMeter | condition | event,
  tolerance, escalationPolicy, terminationCondition,
  supersessionPolicy, complianceEvidenceRequirements[]
}

DueProjection = evaluate(requirement, target, configuration,
                         meterLineage, eventHistory, condition,
                         deferrals, knownAt, evaluatorVersion)
```

- Meters are independent typed histories. Replacing an odometer, battery, controller or component never resets prior readings.

- A requirement may use several thresholds; the earliest applicable due boundary controls unless the rule explicitly combines them.

- Missing meter history produces unknown or a conservative declared rule, never a silently estimated exact value.

- Deferral is an authorized record with basis, limits, compensating actions, expiry and follow-up; it is not an edited due date.

- A superseded task remains resolvable for work performed under its revision; projections explain which revision now applies.

### 28.3 Execution step contract

| Step area | Required record |
| --- | --- |
| instruction | procedure identifier/revision, step ID, warnings/cautions, applicability and required qualification |
| precondition | isolation, safe state, environmental condition, access, permits and independent hold points |
| performer | principal, role, qualification/authorization, employer/team, start/end and delegation |
| tool/equipment | asset identity, calibration/serviceability, setup, software version and custody |
| material | part/lot/batch/substance, quantity, source, expiry, certificates, removed disposition and waste |
| observation | as-found/as-left measurements, method, instrument, uncertainty, configuration and evidence |
| deviation | approved deviation or unplanned variance, impact assessment, authority and corrective action |
| completion | status, skipped/not-applicable rationale, timestamp, signature/proof and linked findings |

### 28.4 Finding, defect, damage, failure, and cause graph

Observed condition, requirement violation, functional failure, damage event and causal hypothesis are different records. A root-cause analysis may be revised without changing the original crack photograph, power-loss event or test result. Repair records link what was addressed; they do not erase the finding.

| Record | Minimum content | Allowed relation |
| --- | --- | --- |
| ConditionObservation | target, property, method, result, uncertainty, time/configuration and evidence | supports finding; updates projection |
| Finding | requirement/expected state, observed deviation, severity, status and disposition | concerns item/function; foundBy task |
| FailureEvent | lost/degraded/unintended function, phase, symptoms, detection, response and consequence | mayContributeTo incident; affects capability |
| DamageEvent | cause event if known, location/geometry/material, extent and propagation concern | resultsIn condition/finding |
| CausalAssertion | candidate cause/mechanism, evidence, alternatives, confidence semantics and reviewer | supports/disputes cause; never overwrites event |
| RepairDefinition | approved method, limits, inspection, life limit and approval basis | addresses finding/damage |
| RepairExecution | actual preparation/material/process/cure/measurements/NDT/release | implements definition; creates configuration |

### 28.5 Cost, inventory, sustainability, and warranty ledgers

| Ledger | Required context |
| --- | --- |
| inventory movement | item/material identity, quantity, from/to custody/location, reason, valuation basis and receipt |
| labor | work package/step, role, time basis, rate source, currency and approval; private personnel detail scoped |
| external service | provider, purchase order, scope, tax, invoice, warranty and evidence artifacts |
| warranty claim | coverage instrument, defect/failure, configuration, evidence, submitted/accepted/denied and recovery |
| environmental flow | material/energy/waste quantity, method, boundary, factor/source, allocation and uncertainty |
| asset value effect | appraisal input relation only; maintenance spend never automatically equals value increase |

```text
No accounting by note parsing
Money, inventory, warranty recovery and environmental claims are typed records with exact quantities and parties. A mechanic's narrative may explain them but cannot substitute for a balanced transaction or source document.
```

# 29. Telemetry, media, and evidence ingestion data plane

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.29 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:4d672feab94922b687f49a3d2471c4255cb3726a3700ad1ba36d890374848e17

High-rate samples and large media do not belong inside the semantic ledger. The ingestion plane validates producer identity, capture context, clock quality, schema and chunk integrity; stores immutable artifacts; then appends a compact manifest record that makes the data discoverable and reproducible. A segment can be useful despite dropout, clock drift or expired calibration only when those limitations remain explicit.

### 29.1 Capture session and producer contract

| Area | Required fields |
| --- | --- |
| scope | asset/assembly, exact configuration, operation/mission/phase, operator/controller, environment and privacy context |
| producer | device/controller/logger instance, hardware/firmware/software build, boot/session ID, key epoch and attestation state |
| clock | clock ID, epoch, resolution, monotonicity, synchronization method, offset, drift model, uncertainty and discontinuities |
| channel schema | stable channel ID, phenomenon/quantity kind, feature of interest, datatype, unit, frame, sign convention and null/quality encoding |
| sampling | nominal/variable rate, trigger, pre/post window, resampling/interpolation policy, anti-alias/filter and event-versus-periodic behavior |
| calibration | sensor/measurement-chain calibration, validity, coefficients/artifact, environment and applicability |
| segmentation | producer sequence range, start/end clocks, target duration/size, compression, encryption and rolling digest policy |
| policy | field sensitivity, precise-location treatment, retention, consent/legal basis, permitted derivations, export and disclosure |

### 29.2 SegmentManifest v2

```text
Telemetry segment manifest - illustrative JSON
{
  "segmentId": "seg:sha256:...",
  "captureSessionId": "018f...55",
  "assetId": "018f...aa",
  "configurationId": "cfg:sha256:...",
  "operationSegmentId": "record:operation-segment",
  "producer": {"deviceId": "018f...d1", "bootId": "boot:...", "sequence": {"first": "19000", "last": "24999"}},
  "time": {"sourceStart": "812.004000", "sourceEnd": "872.004000", "clockModelRef": "record:clock-model"},
  "schemaRef": {"id": "schema:rtracer.telemetry.road-basic/v3", "digest": "sha256:..."},
  "channels": [{"channelId": "wheel.speed.fl", "column": "c17", "unit": "km/h", "qualityColumn": "q17"}],
  "artifact": {"artifactId": "artifact:...", "format": "application/vnd.apache.parquet", "digest": "sha256:...", "bytes": "2481901"},
  "statistics": {"rows": "6000", "dropouts": "4", "duplicateSamples": "0", "clockUncertaintySeconds": "0.002"},
  "privacyPolicyRef": "policy:vehicle-telemetry-private/v2"
}
```

### 29.3 Ingestion stages and disposition

| Stage | Checks | Failure behavior |
| --- | --- | --- |
| admission | tenant/device authorization, content length, media type, rate/quota and session state | reject without revealing inaccessible entity state |
| transport | chunk framing, compression ratio, encryption/authentication, nonce/replay window and timeout | retry-safe rejection or bounded quarantine |
| syntax | format parser limits, schema footer/header, row/column counts, type and dictionary bounds | quarantine original bytes; no partial projection |
| integrity | artifact digest, segment ID, producer sequence, duplicate/collision and object-store confirmation | deduplicate exact retry; quarantine equivocation |
| semantic | channel schema lock, units, frames, clock model, calibration, configuration and operation references | accept-with-quality, quarantine or reject per rule |
| privacy | sensitive channels, precise location, people/media, retention, export and derived-feature permission | encrypt/segregate, redact projection or reject |
| commit | artifact durable, manifest canonical, subject links and outbox atomic | compensate orphan object or retry transaction |
| post-process | statistics, thumbnails, indexes, derived metrics and anomaly jobs | retry independently; manifest remains source |

### 29.4 Time, ordering, and duplicate semantics

1. Producer sequence establishes order within one boot/session only; it is never assumed globally unique.

1. Source time, synchronized estimate, server arrival time and ledger recorded time are retained separately.

1. A clock discontinuity creates a new clock-model interval; timestamps are not rewritten to hide the discontinuity.

1. Exact duplicate segment ID plus digest is idempotent. Same ID/index with different bytes is equivocation and quarantined.

1. Late and out-of-order segments are accepted when policy allows, then projections revise their completeness watermark.

1. Cross-device correlation reports uncertainty. Apparent simultaneity within uncertain clocks is not ordered fact.

1. Event-time windows close under a declared lateness policy; a later segment can trigger correction/rebuild, not historical deletion.

### 29.5 Channel evolution and adapters

| Change | Treatment |
| --- | --- |
| new optional channel | new schema version; old segments remain valid; projection exposes coverage |
| channel rename | stable channel concept plus alias/migration; original source name retained |
| unit change | new schema version; exact conversion adapter and original unit/value preserved |
| datatype widening | compatibility declared only if all old values round-trip and null/quality semantics match |
| scale/offset correction | calibration or adapter record; never rewrite raw column bytes |
| different bus/source | new source namespace and mapping evidence; same physical phenomenon may remain separate observations |
| proprietary encrypted field | opaque namespaced column may be retained; accessibility and key state explicit |
| unsupported future channel | round-trip artifact and manifest; mark unsupported without discarding segment |

### 29.6 Media and sensor-fusion evidence

| Evidence family | Minimum provenance |
| --- | --- |
| camera/photo/video | capture device/lens, orientation, timing, exposure, calibration, edits, people/plate/location privacy and rights |
| audio | microphone chain, gain, clock, channel geometry, speech/voice rights, redaction and synthetic/edited disclosure |
| LiDAR/radar/sonar | sensor pose/frame, scan pattern, timing, environment, calibration, returns/filtering and safety constraints |
| GNSS/navigation | receiver/antenna, constellation/source, datum/frame, solution type, covariance, corrections and outage/spoof flags |
| derived fusion | input segment/artifact IDs, time alignment, transforms, algorithm/model digest, parameters, output uncertainty and receipt |
| annotation | annotator/agent, vocabulary version, geometry/time span, confidence semantics, review and source evidence |

### 29.7 Hot, warm, and archival data classes

| Class | Purpose | Rules |
| --- | --- | --- |
| hot | recent operations, live owner view and bounded alerts | short retention, strict access, backpressure, no public precise location |
| warm | recent history, comparisons, maintenance and event media | indexed segments, derived summaries, policy-bound retrieval |
| cold | long-term lifecycle evidence and regulatory/owner archive | immutable object lock where required, integrity scrub and restore tests |
| legal/incident hold | preservation under authorized process | separate hold authority, scope, review, expiry and audit; not a blanket policy override |
| expired/deleted | retention or lawful deletion outcome | key/payload disposal plus non-sensitive tombstone and deletion receipt when appropriate |

# 30. Runtime architecture, persistence, replay, scale, and recovery

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.30 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:543792d64de69ff8b19185f593b5f5e0f695fc47ce8d97851eefa80aa380fab7

The runtime uses one provenance spine and several explicitly subordinate stores. This is not accidental polyglot persistence: semantic records, high-volume telemetry, immutable artifacts, full-text discovery, graph traversal and low-latency feeds have different access patterns. Only the canonical ledger and artifact digests are required to rebuild the others.

![Diagram showing the append-only semantic ledger as the source of record with object storage, telemetry lake, search, graph projections, cache and feeds as specialized rebuildable stores.](/substrate/v1.4.1/assets/media/image9.png)

Specialized stores accelerate access; none may silently mutate semantic history.

### 30.1 Store responsibility matrix

| Logical store | Authoritative content | Rebuild / consistency |
| --- | --- | --- |
| semantic ledger | record envelope, canonical bytes/digest, subjects, time, proofs, grants, receipts and outbox | primary transactional authority; append-only backups and point-in-time recovery |
| artifact store | media, documents, raw telemetry, signatures, exports and model artifacts | content-addressed; manifest/digest audit; replicated independently |
| telemetry lake | columnar sample segments, channel metadata and partition statistics | manifest-authoritative; indexes/catalog rebuildable from manifests |
| graph projection | configuration, topology, relationships, provenance and continuity traversals | eventually consistent; checkpointed deterministic replay |
| search index | policy-safe text, aliases, facets, recipes, public fields and discoverability ranking | eventually consistent; never stores secret source as hidden searchable field |
| profile/feed cache | audience-specific serialized views with ETag/version | short-lived; key includes policy/schema/knownAt/location class |
| analytics warehouse | de-identified/authorized facts and derived aggregates | purpose-bound exports with lineage and revocation/deletion propagation |

### 30.2 Aggregate stream head and fenced writer

| Field | Purpose / invariant |
| --- | --- |
| tenant_id + stream_id | Stable address of one independently ordered aggregate stream; neither value is inferred from a display name. |
| stream_kind | Declares the aggregate contract and legal transition set, such as entity, configuration, auction, action or settlement. |
| last_stream_seq | Monotonic sequence inside this stream. A write supplies the expected prior value or is rejected as a concurrency conflict. |
| last_record_id + digest | Tail of the semantic hash chain. It makes omission or rewriting detectable when receipts are compared. |
| writer_epoch | Fencing token issued to the active writer lease. A delayed writer from an earlier epoch cannot append after failover. |
| home_cell | Current write cell for routing and recovery; moving it requires an explicit fenced handoff. |
| logical_shard_id | Stable routing to one logical ledger shard. The receipt-chain tail exists only on ShardHead. |

- Only one writer epoch is accepted for a stream at a time; lease expiry alone is insufficient without fencing.

- RTracer promises no global semantic order across independent streams. Cross-stream views expose their contributing checkpoints.

- A hash chain is tamper-evident, not magically tamper-proof. Independent receipt anchoring, backups and comparison are still required.

- Cross-stream workflows are explicit sagas with durable intents, compensations and reconciliation—not hidden distributed transactions.

### 30.3 Atomic append and transactional outbox

```text
Atomic append and canonical outbox - v1.4 pseudocode
BEGIN
  lock idempotency_binding(tenant, principal, operation, key)
  if existing.request_digest == request_digest: return existing result
  if existing and digest differs: quarantine EQUIVOCATION
  lock ShardHead rows in canonical shard-key order
  lock stream_head rows in canonical stream-key order
  recheck writer, policy, registry and shard-map epochs
  require expected_stream_seq == stream_head.last_stream_seq
  nextStreamSequence = stream_head.last_stream_seq + 1
  nextCommitSequence = shard_head.last_commit_sequence + 1
  build receipt using shard_head.last_receipt_digest
  insert record, receipt, exactly one canonical admission event and outbox row
  advance stream_head and ShardHead in the same transaction
COMMIT

Publisher emits the canonical lane by tenant + logicalShardId + chainEpoch in
commitSequence order. Consumer deduplication, projection mutation and checkpoint
advance commit atomically over a contiguous applied prefix.
BEGIN
  lock idempotency_binding(tenant, principal, key)
  if existing.request_digest == request_digest: return existing.result
  if existing and digest differs: quarantine EQUIVOCATION
  lock stream_head(tenant, stream_id)
  require writer_epoch == stream_head.writer_epoch
  require expected_stream_seq == stream_head.last_stream_seq
  validate canonical record and authorization at policy checkpoint
  assign tenant ledger_seq and next stream_seq
  insert record_ledger, record_subject, record_relation
  insert idempotency_binding(request_digest, result_record_id)
  insert outbox_event(ledger_seq, canonical_event_digest)
  advance stream_head(stream_seq, record_id, record_digest, receipt_digest)
COMMIT

Publisher claims outbox rows, emits at-least-once, records acknowledgement.
Consumers deduplicate by tenant + ledger_seq + event kind and checkpoint only
after the projection mutation is durable.
```

```text
Exactly-once is an outcome, not a transport promise
The platform assumes messages can be duplicated, delayed and reordered. Idempotent writes, immutable sequence IDs, deterministic consumers and durable checkpoints make the resulting projection effectively once-applied.
```

### 30.4 Projection contract

| Area | Required declaration |
| --- | --- |
| identity | projection ID, version, code digest, schema/pack lock and owning team |
| input | tenant/logical shard epoch, starting/ending commitSequence, required record families and dependency projections |
| policy | audience, purpose, privacy/rights version and location precision class |
| determinism | same ordered inputs and versions produce byte-equivalent canonical projection output |
| checkpoint | last committed sequence, state digest, watermark, lag and rebuild generation |
| correction | late/corrected inputs update the projection; prior materializations may remain in audit storage |
| failure | poison event quarantine, retry policy, skip prohibition, degraded status and operator receipt |
| explanation | input record IDs, conflict decisions, derivation receipts and known/valid time |

### 30.5 Partitioning and tenancy

| Concern | Default | Boundary rule |
| --- | --- | --- |
| ledger partition | tenant/realm then ordered sequence | Cross-tenant global order is neither promised nor required |
| entity affinity | entity hash inside tenant | Multi-entity transaction uses coordinator or explicit eventual workflow |
| telemetry | tenant / time / asset bucket / schema | Partition choice never becomes semantic identity |
| artifact | content-addressed object plus tenant policy envelope | Deduplicated bytes do not imply shared authorization |
| search/graph | tenant and disclosure class | Private graph edges cannot leak through counts, ranking or timing |
| keys | tenant data-encryption key hierarchy and purpose-specific subkeys | Ownership transfer does not transfer tenant/platform keys |
| regional residency | policy-selected write region and replicas | Exports/replicas require explicit jurisdiction and receipt |

### 30.6 Consistency model

| Surface | Consistency | Client-visible contract |
| --- | --- | --- |
| record append | linearizable for one stream and one logical shard commit prefix | Idempotency, next streamSequence, and next commitSequence observed atomically |
| read-your-writes | supported by minimum checkpoint token | Client may request projection checkpoint >= committed sequence |
| cross-projection view | eventually consistent | Response exposes each projection checkpoint; no false single snapshot |
| auction close/settlement | strongly serialized per auction | Trusted close decision, bid eligibility and sale authority evaluated once |
| social feed/search | eventually consistent | Staleness acceptable within declared SLO; deletion/revocation priority lane |
| physical control | outside this platform plane | RTracer record latency is not a safety-control guarantee |

### 30.7 Capacity and performance model

Capacity planning starts with record and artifact classes, not vehicle count alone. One museum car may produce a few records per month; a race car may produce millions of samples per session; a public vehicle agent may produce many reads with few writes.

| Dimension | Planning input | Control |
| --- | --- | --- |
| semantic writes | records/second, canonical bytes, subject links and outbox fanout | batch-free atomic writes, partition headroom and backpressure |
| telemetry | samples/second, channels, bytes/sample, duty cycle and compression | edge filtering, chunk size, multipart upload and tiering |
| media | captures/hour, resolution/duration, derivatives and retention | direct object upload, digest verification and asynchronous processing |
| read traffic | profile/feed/search/query mix, audience policy and cacheability | checkpoint-aware cache, pagination, cost budget and rate limits |
| graph complexity | nodes/edges/configuration, path depth and time slices | bounded queries, precomputed views and explainable truncation |
| replay | ledger records, projection cost, parallel partitions and target recovery time | versioned snapshots/checkpoints plus full reproducibility test |

### 30.8 Service objectives and error budgets

| Surface | Objective family | Important qualification |
| --- | --- | --- |
| canonical append | availability and p95/p99 latency by write class | Excludes authorized rejection; includes atomic durability and receipt |
| owner projection | checkpoint lag and read availability | Must expose staleness token; read-your-write option budgeted |
| public profile/feed | freshness, cache hit, correction/removal propagation | Privacy revocation has tighter objective than ordinary content |
| telemetry admission | accepted bytes/sec, queue age, dropout and manifest latency | Backpressure before memory/disk exhaustion; no silent sampling |
| auction | bid acceptance/ordering and close/settlement availability | No degraded close that changes winner semantics |
| recovery | RPO/RTO per ledger, artifact, telemetry and projections | Canonical history and keys have stricter targets than rebuildable indexes |

### 30.9 Backup, disaster recovery, and integrity scrubbing

1. Continuously replicate canonical ledger logs and object manifests to an administratively independent failure domain.

1. Back up schema/vocabulary/pack registries and encryption/key metadata under separate access controls; encrypted data without recoverable authorized keys is lost.

1. Verify backups by scheduled restore into an isolated environment, then replay projections and compare known digests/checkpoints.

1. Run periodic artifact integrity scrubs against stored digests; repair from replica or mark unavailable with an incident record.

1. Maintain a documented failover decision, split-brain prevention, recovery sequence and reconciliation path for writes accepted near outage boundaries.

1. Record recovery actions and data-loss boundaries as operational receipts; do not imply perfect continuity when RPO was exceeded.

1. Exercise tenant-level export and restoration so a local failure or commercial migration is not dependent on the original platform instance.

# 31. Governed vehicle-agent, policy, privacy, and market runtime

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.31 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:6880a4e5525fd645d457adebdf6e5d0723c8f185894dc1f3a5a4395a14d8d697

The vehicle can be the account without being a legal person, owner, unrestricted spender or physical controller. A vehicle agent is a governed software actor representing one or more asset personas for declared beneficiaries. It reads a policy-filtered evidence projection, produces drafts or bounded proposals, and receives only the minimum current grants needed for approved digital actions.

![State machine for a governed vehicle-agent action progressing through proposed, evaluated, confirmed, reserved, executing, reconciling, settled or failed states, with physical control isolated.](/substrate/v1.4.1/assets/media/image10.png)

An agent proposal is inert until policy, confirmation and connector boundaries admit it.

### 31.1 Principal, agent, beneficiary, and provider

| Role | Meaning | Boundary |
| --- | --- | --- |
| principal | person or legal entity authorizing representation or action | Must have authority for the exact asset/right/resource; ownership alone may be insufficient |
| vehicle persona | versioned character/canon/voice/visual identity associated with an asset | Not automatically transferred with title, custody or profile admin |
| vehicle agent | software actor using an approved persona, context projection and skill set | No inherent rights; every read/write/action is granted |
| beneficiary | party for whose interest the action is performed or revenue held | May differ from principal, owner, fan or operator |
| operator/steward | human/team reviewing content and managing day-to-day profile activity | Cannot exceed delegated scope; actions remain attributable |
| service provider | ticketing, merchant, auction, payment, advertising, media or event connector | External terms/status remain source assertions, not platform truth |
| audience/member | viewer, follower, bidder, buyer, event participant or applicant | Consent, privacy, age/jurisdiction and eligibility may differ by action |

### 31.2 Grant and policy-evaluation contract

```text
Scoped grant and policy decision
ActionGrant {
  grantId, issuerPrincipalId, granteeAgentId, beneficiaryIds[],
  actions[], resourceSelectors[], purpose, audience,
  validTime, jurisdiction, channel, confirmationMode,
  monetaryLimits?, rateLimits?, locationLimits?, dataMinimization,
  requiredDuties[], prohibitedEffects[], delegationDepth,
  policyRef, policyDigest, revocationEpoch, proofRefs[]
}

Decision = evaluate(subjectAttributes, resourceAttributes,
                    requestedAction, purpose, environment,
                    currentGrantSet, prohibitions, duties,
                    policyVersion, knownAt)
```

| Input | Examples |
| --- | --- |
| subject | principal/agent identity, role, authentication strength, delegation chain, age/eligibility and risk state |
| resource | asset, profile, telemetry field, media, money, inventory, seat, bid, listing, persona or connector |
| action | read, derive, draft, publish, message, reserve, buy, bid, refund, transfer, export or administer |
| purpose | storytelling, maintenance, event help, recruitment, sale, analytics, safety response or legal obligation |
| environment | time, location class, jurisdiction, device/session, network, channel, incident state and transaction risk |
| duties | confirmation, disclosure, attribution, logging, budget reservation, human review, deletion or revenue share |
| decision | permit, deny, indeterminate or permit-with-duties; explanation and matched policy clauses |

```text
Deny by construction
The social and commerce agent runtime receives no credentials, network route, API method, schema, grant type or connector capable of steering, braking, propulsion, flight-control, payload release or other physical actuation.
```

### 31.3 Grounded content transaction

| Stage | Durable receipt |
| --- | --- |
| request | campaign/event/conversation goal, audience, channel, constraints, tone and prohibited topics |
| retrieve | policy-filtered record IDs, truth lanes, as-of times, unavailable/conflicting evidence and coverage |
| plan | claim plan, creative devices, required disclosures, media needs and citation/attribution map |
| generate | model/prompt/tool versions, inputs, candidate output, synthetic-media lineage and unsupported claim flags |
| ground | sentence/scene-to-record links, contradiction checks, uncertainty wording and creative-lane markings |
| review | automated policy result, human decision/edit diff where required, rights and privacy checks |
| publish | canonical content artifact, platform/location IDs, current grant, schedule and provider receipt |
| engage | conversation/action proposals, moderation, rate limits, escalation and member consent |
| correct/retract | original publication, corrected claim/artifact, reason, notification scope and retained history |
| measure | reach/engagement/conversion under approved analytics purpose; no hidden truth or value promotion |

### 31.4 Persona versioning and succession

| Plane | Required content |
| --- | --- |
| canon | name, biography, voice boundaries, known lore, creative motifs, sensitive topics and version |
| rights | voice, likeness, marks, music, character/franchise, vehicle design, media and territory/channel grants |
| representation | which asset/configuration/persona is represented and who may approve or operate the agent |
| memory | public interactions, owner/team assertions, factual evidence links, private notes and retention classes |
| succession | owner/team transfer, agent retirement, persona transfer/license, replica, rebuild, destruction or fork policy |
| revocation | kill switch, grant epoch, model/voice asset withdrawal, content freeze and follower notification behavior |

### 31.5 Spotting, invitations, and location privacy

1. Create a spotting observation from lawful public signals with capture time/place precision, media rights and people/plate privacy.

1. Resolve only to candidates; image similarity, plate, VIN or logo never creates a profile merge or ownership assertion.

1. Publish a coarsened/delayed location and redacted media projection appropriate to the asset risk and owner preference.

1. Deliver a physical/QR/NFC invitation that lets an apparent owner, custodian or team claim, dispute or ignore the candidate profile.

1. Verify control through risk-appropriate evidence without publicly exposing private documents or live location.

1. Record the car story as attributed interview assertions; approve public excerpts and keep private source material scoped.

1. Use resulting interests only for consented event/service recommendations; never infer sensitive human traits from vehicle association.

### 31.6 Recommendation and advertising policy

| Input class | Permitted default | Prohibited default |
| --- | --- | --- |
| public vehicle facts | event/part/service relevance using declared configuration and general location | claiming endorsement or exposing a hidden owner |
| owner preferences | purpose-specific personalization and frequency controls | reuse for unrelated targeting without basis |
| maintenance/condition | consented service reminders and compatible-part discovery | selling raw defects, location or risk to unrelated advertisers |
| telemetry | owner-facing insights and explicitly opted-in program | silent behavioral advertising or insurance/employment inference |
| member interaction | conversation continuity and requested event/merch help | sensitive profiling, manipulative urgency or dark patterns |
| sponsorship | clearly labeled campaign with scope, creative approval and measurement | undisclosed paid speech or fictional claim presented as evidence |

### 31.7 Commerce object model and accounting

| Object | Minimum content |
| --- | --- |
| catalog item | product/service/event/seat/training/merch identifier, provider, availability, terms, tax and fulfillment |
| quote | priced terms, currency, validity, assumptions, inventory and provider receipt |
| reservation | resource hold, expiry, beneficiary, price lock, release and idempotency |
| order | buyer/principal, line items, terms acceptance, totals, tax, payment intent and status |
| payment/settlement | provider references, authorization/capture/refund, fees, currency, reconciliation and dispute |
| entitlement | ticket, membership, download, training slot, merchandise claim or access right and transfer policy |
| revenue share | beneficiary, basis, rate/tier, deductions, period, accrual, payable and audit |
| invoice/receipt | legal issuer/customer fields where applicable, line/tax totals and immutable artifact |

### 31.8 Auction and bid transaction

| Phase | Serialized decision |
| --- | --- |
| draft | subject/configuration/condition, seller and sale authority, disclosures, jurisdiction and policy versions |
| scheduled | open/close clocks, reserve/increment/anti-sniping, bidder eligibility, inspection and settlement terms |
| open | immutable bid admission with trusted receive time, currency, amount, bidder eligibility and idempotency |
| paused/cancelled | permitted trigger, authority, bidder notice, hold release and restart/relist behavior |
| closed | close decision receipt binds exact eligible bid set, policy and winner/no-sale result |
| settling | identity/title checks, payment/escrow, inspection, taxes/fees, documents, delivery and approvals |
| settled/failed | transaction, custody/title/rights consequences, payout/refund, dispute and retained audit |

```text
Followers and bids do not own the vehicle
Popularity, appraisal, asking price, standing offer, highest eligible bid, transaction price and long-term brand value remain distinct. No market projection changes title, custody, persona rights or sale authority without its own governed records.
```

### 31.9 Recruitment, internships, and serious-engineering pathways

- A challenge, race, training session or vehicle project publishes skills, eligibility, consent, evidence and review criteria.

- Candidate portfolios and telemetry contributions remain attributed to the person/team; the vehicle profile can reference but not own them.

- Agent recommendations may explain opportunities and help assemble an application, but high-impact selection stays human-reviewed.

- Hiring, education, immigration, disability, age and other sensitive decisions use dedicated lawful processes outside the social-ranking system.

- Every referral, interview invitation, decision status and withdrawal carries a purpose-bound receipt and retention policy.

### 31.10 Risk tiers and dispatch-time reevaluation

| Tier | Examples | Minimum gate |
| --- | --- | --- |
| R0 observe | read a public profile, summarize declared telemetry | Policy-filtered read and source/checkpoint disclosure |
| R1 reversible expression | draft or schedule an ordinary post, save an event | Current content grant, grounding and easy reversal |
| R2 bounded external effect | send an invitation, reserve a free place, create a merch cart | Named provider scope, recipient/purpose limit, rate limit and receipt |
| R3 money or binding commitment | buy a ticket, place an eligible bid, accept commercial terms | Fresh human confirmation over exact amount/terms plus economic mandate and settlement identity |
| R4 high-impact representation | publish sponsorship, submit recruitment material, transfer persona rights | Dual-control or designated approver, rights review and non-repudiable decision receipt |
| R5 safety-critical physical control | steering, propulsion, braking, flight control, hazardous actuation | Unavailable to the social/commerce agent plane; use a separately certified controller and gateway |

Risk is evaluated twice: when a proposal is formed and immediately before dispatch. The second decision binds the exact canonical proposal digest, current grant epoch, policy version, beneficiary, provider terms, money total, confirmation artifact and environmental context. A stale approval cannot authorize a changed payload.

### 31.11 Economic mandates and double-entry journal

A vehicle may earn and spend under delegated management, but it is an accounting dimension—not an unqualified legal owner of funds. Every balance belongs to a named legal account holder or escrow arrangement, with the vehicle/persona/mission carried as reporting dimensions and the beneficiary made explicit.

```text
Economic mandate and journal contract
EconomicMandate {
  mandateId, principalId, beneficiaryId, agentId,
  allowedActionKinds[], allowedMerchantCategories[],
  perActionMinorLimit, periodMinorLimit, currency,
  validInterval, confirmationThreshold, grantEpoch
}

JournalEntry {
  journalEntryId, economicEventId, bookedAt, effectiveAt,
  currency, lines[{accountId, debitMinor, creditMinor,
                   vehicleId?, personaId?, missionId?, providerRef?}],
  sourceReceiptIds[], reversalOf?
}

Invariant per currency: sum(debitMinor) == sum(creditMinor).
Amounts are integer minor units. Corrections append reversing and replacement
entries; posted journal rows are never edited in place.
```

- Escrow cash, customer funds, provider payables, taxes, platform fees and beneficiary earnings remain separate accounts; a single net 'vehicle balance' is only a derived report.

- Quote, reservation, order, payment authorization, capture, refund, payout and chargeback are different economic events linked by provider receipts.

- Every revenue share states the calculation basis, exclusions, fee/tax treatment, period, rounding rule, currency conversion source and dispute window.

- Mandate exhaustion, grant revocation, owner/beneficiary change or unusual fraud signals stop new commitments without rewriting completed accounting history.

### 31.12 Unknown effects, reconciliation, and compensation

| Connector outcome | Required platform behavior |
| --- | --- |
| definitive success | Persist provider receipt, resulting entitlement/economic event and final action receipt before reporting success. |
| definitive rejection | Persist normalized rejection and safe provider evidence; release local reservations and do not retry unless policy permits a new proposal. |
| timeout before dispatch evidence | Treat as not sent only when the connector proves no request left the boundary; otherwise outcome is unknown. |
| timeout after possible effect | Enter UNKNOWN_EFFECT, query/reconcile by stable external idempotency key and prohibit blind re-execution. |
| success followed by local commit failure | Recover from outbox/reconciliation using the same provider operation ID; never create a second external effect. |
| partial multi-provider workflow | Run the declared saga: complete, compensate or escalate each step; retain both attempted and compensating receipts. |
| non-compensable effect | Require stronger pre-dispatch confirmation and an operator resolution path; never claim atomic rollback. |

```text
Connector retries are financial and reputational decisions
A network timeout does not mean the ticket, bid, post or payment failed. The stable action ID and provider idempotency key must be reconciled before a retry. UNKNOWN_EFFECT is a first-class durable state, not an exception string.
```

# 32. API, event, query, SDK, and conformance implementation

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.32 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:b4d03b13113dbbe263726178b73f2829d811eb9a26e1dc7e4d1d53e190ff1852

The developer surface must make the safe path the easy path. Canonical writes are narrow; expressive reads operate over policy-bound projections; high-volume artifacts use direct upload plus manifests; events are at-least-once; every consequential action returns an auditable receipt. OpenAPI or AsyncAPI documents describe transport contracts but remain subordinate to immutable RTracer schemas and vocabularies.

### 32.1 HTTP resource conventions

| Surface | Request contract | Response contract |
| --- | --- | --- |
| POST /v1/records | Idempotency-Key, exact Content-Type/schema, optional request signature | 201 record receipt; 200 exact retry; 409 equivocation/conflict |
| GET /v1/records/{id} | authorization, representation media type | Canonical record or policy projection; immutable ETag |
| GET /v1/entities/{id} | projection, validAt, knownAt, minimumCheckpoint | Audience-specific entity view plus explanation/checkpoint |
| GET /v1/entities/{id}/timeline | record families, cursor snapshot, time filters and conflict mode | Stable page with next cursor bound to same ledger watermark |
| POST /v1/query | bounded typed query AST, cost budget, projection policy | Results, truncation/cost, input checkpoint and explanation |
| POST /v1/artifacts/uploads | media type, size, digest/algorithm, policy and purpose | Short-lived upload capability; no semantic record yet |
| POST /v1/telemetry/segments | artifact confirmation and SegmentManifest | Manifest receipt, quality disposition and checkpoint |
| POST /v1/actions | proposal, requested grant, confirmation mode and idempotency | Inert action ID and policy evaluation, never implicit execution |
| POST /v1/auctions/{id}/bids | bidder session, amount/currency, eligibility evidence and idempotency | Immutable bid admission/rejection receipt and trusted time |
| GET /v1/events | consumer, partition, after sequence, event kinds and projection policy | At-least-once ordered partition stream with checkpoint |

### 32.2 Request integrity, concurrency, and caching

- Idempotency-Key is scoped to tenant, authenticated principal and operation family; reuse with different canonical request bytes is equivocation.

- Mutable workflow resources use ETag/If-Match on their projection version; canonical records themselves are immutable.

- HTTP message signatures may protect selected request components, but authorization still evaluates current grants and context.

- GET responses identify projection/schema/policy version, validAt/knownAt and checkpoint; cache keys include all of them plus disclosure class.

- Sensitive responses default to no-store or private caching. A public cache never receives private source fields before redaction.

- Retries use bounded exponential delay and Retry-After where declared; clients never retry non-idempotent connector effects without a stable action ID.

### 32.3 Problem response profile

```text
Problem Details-compatible error - illustrative JSON
{
  "type": "https://schemas.rtracer.example/problems/port-incompatible/v1",
  "title": "Connection ports are incompatible",
  "status": 422,
  "detail": "The requested fuel outlet cannot connect to an electrical-power inlet.",
  "instance": "urn:rtracer:problem:018f...",
  "code": "RTR-CONFIG-PORT-004",
  "stage": "graph-validation",
  "recordPath": "/body/edges/3",
  "constraintRef": "shape:rtracer.port-compatibility/v2#medium",
  "retryable": false,
  "correlationId": "018f...",
  "safeContext": {"expectedFamily": "electricalPower", "receivedFamily": "fluid"}
}
```

Human detail is not parsed by clients. Stable code, stage, path, constraint and retryability drive program behavior. Errors do not expose whether an inaccessible entity, bid, telemetry stream or private profile exists.

### 32.4 Typed query algebra

| Operator | Meaning | Required limit |
| --- | --- | --- |
| entity | resolve one or more opaque entity roots | tenant/policy scope and maximum seed count |
| asOf | validAt and knownAt temporal slice | explicit defaults; bounded historical window |
| records | filter typed record families, truth lanes, status and authority | maximum result/page and stable snapshot |
| traverse | follow named relationship/graph edges | depth, edge kinds, node count, cycle behavior and time |
| configuration | select snapshot, diff, installed item or topology | exact configuration or declared current projection |
| matchRecipe | evaluate versioned TypeRecipe against facets | explanation and indeterminate/conflict behavior |
| aggregate | count/sum/min/max/histogram over permitted values | privacy threshold, unit compatibility and uncertainty rule |
| search | text/facet/geospatial discovery over a disclosure-safe index | ranking version, location precision and no private inference |
| explain | return inputs, policy decisions, derivations and truncation | redact explanation edges independently where needed |

### 32.5 Event contract

```text
Canonical admission-event transport v1.4
CanonicalAdmissionEvent {
  profile, eventId, eventKind: "ledger.record-admitted.v1",
  ledgerId, tenantId, logicalShardId, chainEpoch, commitSequence,
  streamId, streamSequence, recordId, recordDigest,
  receiptId, receiptDigest, correlationId?, causationId?,
  recordedAt, eventDataDigest
}

One admitted record produces exactly one canonical admission event.
brokerPartitionKey = tenantId || logicalShardId || chainEpoch
Delivery is at-least-once; retries preserve eventId and canonical bytes.
Derived stream topics MUST NOT advance canonical shard checkpoints.
ChangeEvent {
  eventId,
  tenantId,
  partition,
  ledgerSequence,
  eventKind,
  recordId,
  recordType,
  subjectIds[],
  recordedAt,
  canonicalRecordDigest,
  disclosureClass,
  transportAttempt,
  traceContext?
}

Rules: event payload never replaces the canonical record; consumers may fetch
the authorized representation. Delivery is at-least-once. Order is guaranteed
only inside the declared partition. Replays keep the same semantic event ID.
```

### 32.6 Import and export dossier

| Package part | Required content |
| --- | --- |
| manifest | export ID, producing system, tenant/subject scope, purpose, time, format, pack/schema lock and file digests |
| records | canonical records and proofs or authorized projections with loss/disclosure manifest |
| artifacts | included bytes, external references, unavailable/withheld markers, rights and encryption/key instructions |
| vocab/schema | all non-public or non-guaranteed definitions required for offline interpretation |
| ordering | ledger ranges, checkpoints and dependency graph so imports can detect gaps |
| privacy | audience, legal/purpose basis, redactions, location precision, expiry and onward-use duties |
| import receipt | source dossier digest, mappings, created candidates/records, conflicts, quarantines and information loss |

### 32.7 SDK requirements

| SDK area | Contract |
| --- | --- |
| generated types | wire models generated from locked schemas; unknown extensions preserved as bytes/structured value |
| canonicalizer | official conformance vectors; reject ambiguous input before hashing or signing |
| validator | local schema/context/shape registry, resource limits, structured findings and no network fetch |
| auth client | short-lived credentials, current grant/purpose, request integrity, revocation handling and no secret logging |
| idempotency | automatic stable key per logical operation and durable retry state for connector effects |
| pagination | snapshot-bound cursors, checkpoint awareness and transparent rate/backpressure handling |
| telemetry | stream/chunk writer, schema lock, sequence/clock metadata, digest and resumable upload |
| observability | trace context and opaque correlation IDs; sensitive identifiers excluded from labels |

### 32.8 Conformance harness and release gates

1. Validate positive and negative examples for every schema and graph shape, including maximum-size and malformed-input cases.

1. Run canonicalization vectors across every supported language; digests and rejection outcomes must match exactly.

1. Run append/idempotency/outbox fault injection at every transaction boundary and verify no partial canonical state.

1. Replay every projection from empty state and compare canonical outputs/checkpoints with a golden corpus.

1. Run privacy non-interference tests: hidden fields/edges must not leak through status, count, ranking, timing, errors or cache keys.

1. Run agent/market authorization matrices for grant expiry, transfer, revocation, confirmation, money limits and connector retries.

1. Restore ledger, registry, key metadata and artifacts from independent backup; regenerate graph/search/feed views within target RTO.

1. Publish schema/pack/API versions, migration/loss manifests, security review, SLO changes and conformance evidence before activation.

### 32.9 Reference deployment slices

| Slice | Deployable boundary | Exit proof |
| --- | --- | --- |
| S0 identity/evidence | entity, ledger, identifier claims, artifacts, schema registry and owner vault | KUN, RC car and blimp import/export/replay with conflicts |
| S1 configuration/life | snapshots, parts/ports, modification, maintenance, wash/media and condition | Complete before/after and due-history reconstruction |
| S2 telemetry | capture session, manifests, object/lake storage, derived metrics and privacy projection | Raw-to-summary reproducibility and clock/dropout fixtures |
| S3 public vehicle | profile, timeline, spotting claim, followers, grounded drafts and event discovery | No private-location or unsupported-fact leakage |
| S4 governed action | grant/policy engine, confirmations, connectors, ticket/training/merch and receipts | Every effect reconciles or compensates under retry |
| S5 market | appraisal/listing/offers/auction/bids/transaction and provider adapters | Serialized close, eligibility, authority and settlement tests |
| S6 ecosystem | pack registry, SDKs, federation/import/export and partner/tenant governance | Unknown pack round-trip and portable dossier restore |

# 33. Exact wire-level semantic kernel and cryptographic boundaries

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.33 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:e3cd774a239c711bfc256fd5a26277ff0c4ecd7f47fbfc0bb0ec8df8d6353bb7

The earlier contract identifies the right objects; this section removes the remaining implementation discretion. A conforming writer produces one exact RecordCore representation, one representation digest, and zero or more independent proofs. A store then produces a separate admission receipt. Importing the same RecordCore into another tenant or rebuilding another projection must not change the portable record digest.

![Diagram separating received bytes, portable RecordCore, proof set, store admission and rebuildable projection, each with independent digest and authority boundaries.](/substrate/v1.4.1/assets/media/image11.png)

Semantic identity, custody and presentation are related by receipts; they are not one mutable object.

```text
v1.3 portability correction
Storage tenantId, partition, stream sequence, request idempotency, receivedAt and transport identity move out of RecordCore into AdmissionContext/IngestReceipt. A semantically meaningful organization, fleet or jurisdiction remains possible as an attributed subject/relation or administrativeScopeRef. This supersedes the illustrative tenantScope field in Section 26.2 without rewriting already accepted v1.2 records.
```

### 33.1 Conformance tuple and media types

| Tuple member | Normative value / behavior | Why it is separate |
| --- | --- | --- |
| semanticProfile | rtracer.record-core/1.3 | Selects field meaning and required invariants |
| schemaLock | immutable schema ID + semantic version + SHA-256 digest | Selects payload structure without network lookup |
| vocabularyLock | ordered set of namespace/version/digest entries | Fixes every TermRef definition used by the record |
| canonicalProfile | rtracer.jcs-json/1 or rtracer.det-cbor/1 | Selects representation-specific canonical bytes |
| proofProfile | rtracer.cose-sign1/1 or rtracer.http-proof/1 | Selects signature framing and verification method |
| policyProfile | immutable policy bundle ID + digest | Selects admission/disclosure logic, never semantic parsing |
| API media type | application/vnd.rtracer.record+json;version=1.3 | HTTP negotiation is explicit and never inferred from a URL |
| device media type | application/vnd.rtracer.record+cbor;version=1.3 | Constrained encoders use deterministic CBOR under a separate digest |

JSON and CBOR encodings of the same conceptual record have different representation digests. A TranscodingReceipt can assert a lossless mapping between them by naming both digests, both profiles, the transformer digest and the validation corpus. Protocol Buffers may be used internally, but its serialization is not a canonical cross-language signature format.

### 33.2 RecordCore 1.3 exact field contract

| Field | Type / cardinality | Validation and digest semantics |
| --- | --- | --- |
| profile | literal string; 1 | Must equal rtracer.record-core/1.3 |
| recordId | UUIDv7 lowercase; 1 | Globally opaque; included in recordDigest; never reused |
| recordType | TermRef; 1 | Exact vocabulary lock required; no label-derived meaning |
| schemaLock | SchemaLock; 1 | ID, version, digest and canonical profile must resolve locally |
| vocabularyLocks | VocabularyLock[]; 1..32 | Sorted by namespace; duplicate namespace/version forbidden |
| subjects | SubjectRef[]; 1..64 | Set-sorted by role, entityId and qualifier digest; duplicate tuple forbidden |
| validTime | HalfOpenInterval; 1 | World/application time; end absent means open, never unknown |
| authoredAt | Instant; 1 | Producer-asserted creation time; not store transaction time |
| producer | ProducerRef; 1 | Principal, producing system, delegation and key epoch references |
| epistemic | EpistemicContext; 1 | Truth lane, knowledge state, method/confidence semantics and evidence coverage |
| administrativeScopeRef | EntityRef; 0..1 | Portable semantic scope only; never database tenant routing |
| rights | RightsContext; 1 | Immutable disclosure, purpose, retention and onward-duty references |
| body | closed schema object; 1 | No unknown members outside declared extension points |
| extensions | Extension[]; 0..32 | Namespace + schema lock + value; sorted; unknown extensions round-trip |

```text
RecordCore 1.3 canonical JSON shape - shortened digest strings are illustrative
{
  "profile": "rtracer.record-core/1.3",
  "recordId": "019b5f4c-8e27-7a6d-9d12-07ce53ab7a11",
  "recordType": {"id":"urn:rtracer:record:maintenance.execution","version":"1.0.0"},
  "schemaLock": {"id":"urn:rtracer:schema:maintenance.execution","version":"1.0.0",
                 "digest":"sha256:0123456789abcdef...","canonicalProfile":"rtracer.jcs-json/1"},
  "vocabularyLocks": [{"namespace":"urn:rtracer:maintenance:","version":"1.4.0",
                         "digest":"sha256:89abcdef01234567..."}],
  "subjects": [{"entityId":"019b5f40-1d9f-76d9-a9a6-c0ad7bf10001","role":"maintainedAsset"}],
  "validTime": {"start":{"seconds":"1784710800","nanos":0,"scale":"UTC"}},
  "authoredAt": {"seconds":"1784714402","nanos":184000000,"scale":"UTC"},
  "producer": {"principalId":"019b5f41-...","systemId":"019b5f42-...",
               "delegationChainRefs":["urn:rtracer:grant:..."]},
  "epistemic": {"truthLane":"observed","knowledgeState":"known",
                 "methodRef":"urn:rtracer:procedure:service-closeout/v2"},
  "rights": {"disclosurePolicyRef":"urn:rtracer:policy:owner-team/v5",
             "retentionClass":"maintenance-life-plus-10y","purposeRefs":["fleet-care"]},
  "body": {"workOrderId":"019b5f43-...","result":"completed","releaseDecisionRef":"019b5f44-..."},
  "extensions": []
}
```

### 33.3 Primitive lexical grammar

| Primitive | Accepted canonical grammar | Rejected examples |
| --- | --- | --- |
| UUIDv4 root ID | xxxxxxxx-xxxx-4xxx-[89ab]xxx-xxxxxxxxxxxx lowercase hex | nil UUID, uppercase, braces, embedded VIN/MAC/tenant meaning |
| UUIDv7 event ID | xxxxxxxx-xxxx-7xxx-[89ab]xxx-xxxxxxxxxxxx lowercase hex | nil UUID, uppercase, braces, non-v7 for newly minted records/proofs/receipts/events |
| Digest | sha256: followed by exactly 64 lowercase hex characters | base64 ambiguity, uppercase hex, algorithm omitted |
| IntegerString | 0 or -?[1-9][0-9]*; schema bounds digits and sign | +1, 01, -0, exponent form |
| DecimalString | 0, -?[1-9][0-9]*, or either plus .[0-9]+; no trailing zero unless scale requires it | .5, 1., 1e3, NaN, Infinity, -0 |
| Instant | seconds=IntegerString, nanos integer 0..999999999, scale UTC or TAI | local offset, implicit scale, nanos outside range |
| TermRef.id | absolute URI/URN in NFC Unicode; max 512 UTF-8 bytes | relative path, embedded credential, display label as identifier |
| LanguageString | text NFC + valid BCP-47 tag + direction ltr/rtl/auto | language inferred from user locale |
| Money | ISO currency term + integer minor units + exponent table version | binary float, locale-formatted number, currency inferred |

```text
Resource limits are semantic security
Before allocating the full body, reject a record over 8 MiB, nesting depth over 64, object members over 4,096, arrays over 100,000 entries, strings over the field-specific maximum, subjects over 64, extensions over 32 or vocabulary locks over 32. Bulk media and telemetry bytes belong in digest-addressed artifacts, not RecordCore.
```

### 33.4 Domain-separated digests

```text
Digest construction and domain separation
canonicalBytes = canonicalize(recordCore, canonicalProfile)
recordDigest = SHA256(
  UTF8("RTRACER\0RECORDCORE\0v1.3\0") || canonicalBytes
)
bodyDigest = SHA256(
  UTF8("RTRACER\0BODY\0") || canonicalize({recordType, schemaLock, body})
)

ProofTargetV1_4 {
  profile, proofId, targetKind, targetId,
  targetProfile, targetDigest, auxiliaryDigests[], proofPurpose,
  signerPrincipalId, verificationMethodId, keyEpoch, suite,
  createdAt, validUntil?, audience?, challenge?
}

proofTargetDigest = SHA256(
  UTF8("RTRACER\0PROOF-TARGET\0v1.4\0") || JCS(ProofTargetV1_4)
)

Every ProofTarget field is signed. COSE protected suite, key/epoch,
content type and profile MUST repeat and match the target exactly.
canonicalBytes = canonicalize(recordCore, canonicalProfile)
recordDigest = SHA256(
  UTF8("RTRACER\0RECORDCORE\0v1.3\0") || canonicalBytes
)
bodyDigest = SHA256(
  UTF8("RTRACER\0BODY\0") || canonicalize({recordType, schemaLock, body})
)
proofTargetDigest = SHA256(
  UTF8("RTRACER\0PROOF-TARGET\0v1\0") ||
  canonicalize({recordId, recordDigest, proofPurpose, audience?, validUntil?})
)

The byte NUL separators and ASCII domain labels are literal. Hash algorithms,
canonical profiles and target object fields are fixed by profile version.
```

- recordDigest identifies one portable RecordCore representation, including recordId; equal bodyDigest alone never merges records or physical entities.

- Artifact digests use a separate RTRACER\0ARTIFACT domain and include byte length and media type in the manifest, while the digest remains over exact bytes.

- A new canonicalization profile creates a new representation digest. It never replaces or re-labels the prior digest.

- Hash agility is additive: a HashUpgradeAttestation binds an old digest and new digest to the same retained bytes; it does not mutate historical references.

### 33.5 Deterministic canonicalization procedure

1. Read bytes with a media-type-specific strict parser. Reject duplicate map keys before materializing an object and reject ill-formed UTF-8 or Unicode surrogate values.

1. Resolve schemaLock, vocabularyLocks and canonicalProfile from a local content-addressed registry. No validation-time network fetch or mutable latest alias is permitted.

1. Validate structure, cardinality, lexical forms and extension placement before applying any normalization.

1. Validate every internal canonical string against the schema's exact NFC and lexical form; reject non-canonical input rather than silently normalizing signed semantic bytes. Never case-fold an opaque identifier, signature, free text, external serial or source value.

1. External/source identifiers are preserved verbatim in IdentifierAssertion.sourceValue. Any normalized search key is an attributed, versioned derivation and never replaces the source value or enters RecordCore as if supplied by the issuer.

1. A separate pre-admission adapter may convert convenience timestamps and quantities into canonical structured forms, but its output is newly authored input and its TransformationReceipt preserves the source bytes, transformer digest and validation result.

1. Sort object members per the selected profile. Sort only arrays declared set-valued using the schema's total canonical key; preserve every other array order.

1. Serialize exact canonical bytes, reparse them under the same profile, and require byte-for-byte idempotence before digesting.

### 33.6 ProofRecord and verification result

| Field | Requirement |
| --- | --- |
| proofId | UUIDv7; immutable and distinct from target record |
| target | recordId, recordDigest, canonicalProfile and optional bodyDigest |
| purpose | authorship, observation-attestation, registry-assertion, custody, approval, release or transport; never generic signed |
| signer | principal/key ID, issuer/trust domain, key epoch and credential chain references |
| suite | Ed25519 baseline where permitted; P-256 alternative for regulated/FIPS deployments; algorithm confusion forbidden |
| createdAt / validUntil | Instant values; verification evaluates key and proof validity at createdAt and current status separately |
| signature | COSE_Sign1 or exact profile framing over proofTargetDigest |
| verification | append-only result naming verifier, trust bundle, revocation snapshot, algorithm implementation and limitations |

Proof verification returns VALID, INVALID, INDETERMINATE or UNSUPPORTED plus reason codes. VALID means the cryptographic operation and selected trust checks succeeded; it never upgrades the underlying claim from asserted or derived to observed truth.

### 33.7 AdmissionContext and IngestReceipt

```text
Store-local admission objects - deliberately excluded from RecordCore
AdmissionContext {
  tenantId, streamId, expectedStreamSequence, writerEpoch,
  authenticatedPrincipalId, workloadIdentity, requestId,
  idempotencyKey, receivedAt, sourceAddressClass,
  requestedPurpose, admissionPolicyLock
}

IngestReceipt {
  receiptId, tenantId, streamId, streamSequence, shardId, shardPosition,
  recordId, recordDigest, admissionDecision, findingCodes[],
  receivedAt, committedAt, writerEpoch, previousReceiptDigest,
  validatorSetDigest, schemaRegistrySnapshotDigest, policyDecisionRef,
  outboxEventId, storeWorkloadIdentity, receiptDigest, storeProofRef
}
```

The store retains rejected and quarantined input through a FailureReceipt whose disclosure is tightly controlled. A rejection never consumes a stream sequence. An accepted retry with the same idempotency binding returns the original receipt; a different request digest under the same key is EQUIVOCATION and cannot be resolved by last-write-wins.

# 34. Reference ledger engine, concurrency, partitioning, and retention

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.34 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:fea3e23579e5a74d234aeb421ed2f9a2d5b7d994f98caf0b559440ae9fe9147f

A conforming ledger can be implemented with different storage products, but the reference profile uses PostgreSQL because unique constraints, transactional row locks, serializable transactions and an atomic outbox can enforce the write invariants directly. The broker, graph, search, feed and telemetry stores remain disposable projections.

### 34.1 Ordering model and cursors

| Order | Guarantee | Consumer contract |
| --- | --- | --- |
| streamSequence | Gap-free uint64 inside one tenant+stream | Optimistic concurrency and aggregate replay |
| shardPosition | Gap-free uint64 inside one logical shard epoch | Canonical event delivery, projection checkpoint, and receipt chain |
| recordedAt | Store UTC instant; may tie and is not an ordering key | Bitemporal filtering and operations |
| recordId | Time-ordered UUIDv7 for locality only | Opaque identity; never authoritative ordering |
| checkpoint vector | Map logical shard epoch -> inclusive commitSequence | Consistent multi-shard projection watermark |
| public cursor | Authenticated-encrypted token or random server handle bound to query, audience, policy and checkpoint vector | Stable pagination; expires but never silently changes scope |

```text
There is no universal global sequence
Cross-shard order is a partial order expressed through recorded causality, transaction/saga relations and a checkpoint vector. Fabricating one global counter creates a hot lock and a false temporal claim.
```

### 34.2 Reference relational schema

```text
PostgreSQL reference DDL - compact v1.4 skeleton
CREATE TABLE stream_head (
  tenant_id uuid, stream_id uuid, logical_shard_id text,
  last_sequence bigint CHECK(last_sequence>=0), last_record_digest bytea,
  writer_epoch bigint CHECK(writer_epoch>=0),
  PRIMARY KEY(tenant_id,stream_id));

CREATE TABLE shard_head (
  ledger_id uuid, tenant_id uuid, logical_shard_id text, chain_epoch bigint,
  last_commit_sequence bigint CHECK(last_commit_sequence>=0),
  last_receipt_digest bytea NOT NULL, publisher_epoch bigint,
  shard_map_version text,
  PRIMARY KEY(ledger_id,tenant_id,logical_shard_id,chain_epoch));

CREATE TABLE record_ledger (
  ledger_id uuid, tenant_id uuid, logical_shard_id text, chain_epoch bigint,
  commit_sequence bigint CHECK(commit_sequence>0), stream_id uuid,
  stream_sequence bigint, record_id uuid, canonical_bytes bytea,
  record_digest bytea,
  PRIMARY KEY(ledger_id,tenant_id,logical_shard_id,chain_epoch,commit_sequence),
  UNIQUE(tenant_id,record_id), UNIQUE(tenant_id,stream_id,stream_sequence));

CREATE TABLE ingest_receipt (
  receipt_id uuid PRIMARY KEY, ledger_id uuid, tenant_id uuid,
  logical_shard_id text, chain_epoch bigint, commit_sequence bigint,
  previous_receipt_digest bytea, receipt_digest bytea, canonical_event_id uuid,
  UNIQUE(ledger_id,tenant_id,logical_shard_id,chain_epoch,commit_sequence));

Outbox and projection checkpoints reuse the same logical-shard/epoch/commit key.
Appendix O defines every required column, digest and atomicity constraint.
```

- Create 32 hash partitions initially; measure partition size and lock contention before changing. Each partition receives indexes on (stream_id, stream_sequence), (record_type, recorded_at), (recorded_at), and BRIN(valid_start_s) when history is large.

- Keep canonical_bytes and record_digest in PostgreSQL for authoritative replay. Large artifacts remain in object storage and are referenced by immutable manifests.

- Enable and force row-level security for tenant tables, but treat it as defense in depth; the application policy decision and service identity are still mandatory.

- Database roles used by services do not own tables and do not have BYPASSRLS. Migration and break-glass roles are separate, time-bound and fully audited.

### 34.3 Atomic append algorithm

```text
One-record append with fencing, idempotency and outbox
append(ctx, receivedBytes):
  parsed, canonicalBytes, recordDigest = validate_and_canonicalize(receivedBytes)
  requestDigest = H(domain="REQUEST", ctx.operationFamily, canonicalBytes)

  retry SERIALIZABLE transaction on SQLSTATE 40001 with bounded jitter:
    INSERT idempotency_binding(scoped key, requestDigest, status='STARTED')
      ON CONFLICT DO NOTHING
    binding = SELECT idempotency_binding FOR UPDATE by scoped key
    if binding.request_digest != requestDigest: fail EQUIVOCATION
    if binding.status != 'STARTED' or binding.receipt_id is not null:
      return original receipt or in-progress status

    head = SELECT stream_head FOR UPDATE by tenantId, streamId
    require ctx.writerEpoch == head.writer_epoch
    require ctx.expectedStreamSequence == head.last_sequence
    nextSeq = head.last_sequence + 1
    shard = stable_shard(ctx.tenantId, ctx.streamId)
    nextPosition = allocate_shard_position(shard)  # gaps allowed on rollback

    authorize exact recordDigest and current context; fail closed on error
    INSERT record_ledger, subject/relation indexes, ingest_receipt, outbox_event
    UPDATE idempotency_binding SET status='COMMITTED', receipt_id=receiptId
    UPDATE stream_head SET last_sequence=nextSeq, last_record_id=recordId,
           last_receipt_digest=receiptDigest WHERE writer_epoch=ctx.writerEpoch
    COMMIT

  publisher reads committed outbox rows, emits at least once, and marks published.
  Consumer deduplicates by eventId and advances checkpoint with its state atomically.
```

PostgreSQL sequences can produce gaps on rollback; shardPosition therefore orders committed rows but is not required to be gap-free. streamSequence is allocated by the locked stream_head row and is gap-free for accepted records. A writer-epoch mismatch is terminal for that writer, even if it believes its lease remains valid.

### 34.4 Batch append and multi-stream work

| Operation | Atomicity boundary | Failure behavior |
| --- | --- | --- |
| single-stream batch | One transaction; expected starting sequence plus ordered RecordCores | All commit or none; first invalid record rejects batch |
| independent bulk import | One transaction per record or bounded microbatch | Per-item receipt; no fabricated batch atomicity |
| multi-stream semantic transaction | Allowed only when all heads live in one database transaction and lock order is deterministic | Serialize/retry whole transaction; bounded stream count |
| cross-service/cross-store workflow | Durable saga with step receipts | Complete, compensate or escalate; never claim distributed rollback |
| external provider effect | Action transaction plus provider idempotency/reconciliation | UNKNOWN_EFFECT until proven; never blind retry |

### 34.5 Integrity chain and checkpointing

```text
Hash-chain and Merkle checkpoint profile
receiptDigest[n] = SHA256(
  "RTRACER\0INGEST-RECEIPT\0v1\0" ||
  canonical(receipt_without_digest_and_signature)
)

receipt[n].previousReceiptDigest = receiptDigest[n-1] within one ledgerId + tenantId + logicalShardId + chainEpoch. ShardHead stores the only chain tail; commitSequence is gap-free and transactional.
Every 65,536 committed receipts, emit LedgerCheckpoint {
  shardId, firstCommitSequence, lastCommitSequence, merkleRoot, terminalReceiptDigest,
  recordCount, createdAt, signerKeyEpoch, backupSnapshotRefs[]
}

Daily IntegrityScrub recomputes sampled leaves, complete recent windows and
all checkpoint chains; mismatch quarantines the shard from new projection release.
```

### 34.6 Retention, deletion, and legal erasure

| Data class | Default treatment | Deletion semantics |
| --- | --- | --- |
| portable factual RecordCore | Retain according to declared lifecycle/legal class | If erasure is required, destroy protected payload/key material and append ErasureReceipt; never pretend the fact was never processed |
| PII-bearing identifier/evidence | Field or artifact encrypted with scoped data-encryption key | Cryptographic erasure plus object deletion, replicas/backup expiry and verification receipt |
| derived public projection | Rebuildable, short retention | Delete immediately on source/policy change and invalidate cache/search/feed |
| security/audit metadata | Minimized, separately authorized, immutable for defined period | Retain only non-content fields needed for accountability; expire under policy |
| raw telemetry/media | Tiered storage with explicit purpose and expiry | Delete object bytes and segment keys; retain non-identifying manifest tombstone if permitted |
| legal hold | Scoped to named records/artifacts, authority and review date | Suspends only affected disposal; not a blanket tenant freeze |

```text
Append-only does not mean retain every secret forever
The immutable property applies to the audit of decisions and relationships. Privacy-sensitive bytes can be separately encrypted, minimized, redacted and destroyed under an authorized disposal record. A tombstone must not preserve the deleted value in an index, log message, cache key or error string.
```

# 35. Schema, vocabulary, domain-pack, and migration control plane

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.35 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:eefbf44d8e151b826e18be5629a7372232472b5983d8ee034690d4499cc1b4cd

The registry is executable governance. It supplies immutable schemas, canonicalization metadata, vocabulary definitions, validation shapes, policy bundles, migration programs and golden vectors. Runtime services resolve only content-addressed locks that were promoted through the registry state machine; they never execute definitions fetched from a user-controlled URL.

### 35.1 Registry artifact manifest

```text
Content-addressed registry artifact
RegistryArtifact {
  artifactId, artifactKind, namespace, name, semanticVersion,
  contentDigest, canonicalProfile, mediaType, byteLength,
  dependencyConstraints[], resolvedDependencyLocks[],
  compatibilityClaims[], supersedes[], deprecates[],
  publisherPrincipalId, reviewerDecisionRefs[],
  sourceRevision, buildProvenanceRef, signatureRefs[],
  state, activatedAt?, deprecatedAt?, revokedAt?,
  testVectorManifestDigest, resourceBudget, licenseRef
}

artifactKind in {
  jsonSchema, vocabulary, graphShape, typeRecipe, domainPack,
  policyBundle, canonicalProfile, migrationProgram, testCorpus, sdkPackage
}
```

### 35.2 Promotion state machine

| State | Permitted use | Transition gate |
| --- | --- | --- |
| DRAFT | author workspace only | Schema parses; namespace and ownership valid |
| CANDIDATE | isolated test tenants | Dependencies locked; static safety/resource scan passes |
| REVIEWED | release-candidate corpus | Independent semantic/security review decisions recorded |
| ACTIVE | new canonical writes | Compatibility scan, golden vectors, migration/loss plan, signatures and rollout approval |
| DEPRECATED | historical read; new writes warn or deny by policy | Replacement relation and end-of-write date published |
| REVOKED | verification/read only under explicit incident handling | Security/integrity incident and superseding advisory |
| RETIRED | offline archive interpretation | All supported writers migrated; retention and export path confirmed |

Revocation blocks new use; it does not make historical bytes uninterpretable. Verifiers report both validity-at-signing and current registry/key status. Activation is monotonic per namespace/version and never reuses a version string for different bytes.

### 35.3 Dependency resolution and pack sandbox

```text
Deterministic dependency resolver and validation sandbox
resolve(rootArtifacts, registrySnapshot):
  candidates = exact content-addressed versions in snapshot only
  solve semantic-version constraints deterministically:
    1. exact lock wins
    2. otherwise highest non-revoked version satisfying every constraint
    3. tie-break by bytewise artifactId
  reject cycles except vocabulary cross-reference groups explicitly marked cyclic
  reject namespace ownership conflict and duplicate term definitions
  emit RegistryLockfile(sorted artifacts, snapshotDigest, resolverVersion)

validate(pack):
  no network, filesystem, clock, randomness or process access
  bounded AST nodes, recursion depth, input graph size, output findings and CPU
  stratified deterministic rules only; no write or authorization side effects
  timeout/error => INDETERMINATE and fail closed for required safety/policy checks
```

- A domain pack may add terms, recipes, constraints, mappings and stricter rules inside its declared scope. It cannot redefine kernel identity, time, evidence, rights, canonicalization or action semantics.

- Validation and capability rules are pure functions over a bounded input snapshot. They return structured findings/proofs and cannot query live external services.

- External registry adapters produce attributed mapping records. They never insert external class codes directly into core columns or promote a registry assertion into ownership.

- Pack outputs carry the exact lockfile and evaluation engine digest so a later implementation can reproduce the result.

### 35.4 Compatibility classification

| Class | Definition | Required evidence |
| --- | --- | --- |
| wire-backward | new reader accepts every old valid canonical instance | Complete old corpus plus generated boundary values |
| wire-forward | old reader safely preserves/rejects every new instance as declared | Unknown-field/term and extension round-trip vectors |
| semantic-equivalent | projection under stated policy produces the same propositions and units | Bidirectional transform plus proof of no information loss |
| semantic-refinement | new form adds precision without contradicting old meaning | Downcast loss manifest and query-equivalence tests |
| policy-breaking | visibility, authority, purpose or duty meaning changes | New policy/version, impact review, re-consent or explicit migration |
| digest-breaking | canonical bytes differ for previously valid input | New canonical profile; dual verification and representation binding |
| storage-only | indexes/partitions change with identical canonical behavior | Replay/golden digest equality and rollback plan |

### 35.5 Migration program contract

```text
Append-only schema migration
MigrationProgram {
  migrationId, fromSchemaLock, toSchemaLock, programDigest,
  engineProfile, preconditions[], mappingRules[],
  informationLossClasses[], defaultSources[],
  expectedFindingCodes[], goldenVectorsDigest,
  reviewerDecisionRefs[], activationWindow
}

MigrationReceipt {
  sourceRecordId, sourceDigest, targetRecordId, targetDigest,
  migrationId, programDigest, executedAt, executorWorkload,
  findings[], lossManifest[], validationResult, rollbackRelation
}

Rules:
- Historical RecordCore is never rewritten.
- Upcast creates a derived replacement record and explicit relation.
- A supplied default names its source and epistemic lane.
- A lossy transform cannot claim semantic equivalence.
- Bulk activation requires corpus scan counts and quarantine thresholds.
```

### 35.6 Software and definition supply-chain gates

| Gate | Minimum technical evidence |
| --- | --- |
| source | immutable revision, protected review path, named maintainers and source provenance |
| build | hermetic/reproducible where feasible, dependency lock, builder identity and SLSA-style provenance |
| package | artifact digest/signature, SBOM, license, vulnerability status and target compatibility |
| distribution | TUF-style signed metadata roles, expiry, rollback/freeze protection and key rotation |
| activation | canary tenant/partition, conformance evidence, database migration proof and rollback/forward-fix plan |
| runtime | loaded digest exposed in health/receipts; unexpected definition or binary digest prevents readiness |

# 36. Quantity algebra, coordinate frames, clocks, uncertainty, and equivalence

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.36 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:0075336f47b30f7747d633518193abffb9fe45d9510771ecfb9bb3169230715b

A universal mobility system becomes dangerous when every value is merely number plus unit string. RTracer uses an exact quantity kind, dimensional signature, source lexical value, canonical value, method, frame, time support and uncertainty object. Conversion is explicit and reversible where mathematically possible; comparison is prohibited when the measurement locations, frames or correction bases are not equivalent.

### 36.1 QuantityValue 1.3

```text
Exact quantity and uncertainty object
QuantityValue {
  quantityKind: TermRef,
  source: {value: DecimalString, unit: TermRef, resolution?: DecimalString},
  canonical?: {value: DecimalString, unit: TermRef,
               conversionRuleRef: TermRef, conversionReceiptRef: RecordRef},
  dimension: {L, M, T, I, Theta, N, J, angle, information},  # signed small integers
  frameRef?: EntityRef,
  positionRef?: GeometryRef,
  validTime?: HalfOpenInterval,
  uncertainty?: Uncertainty,
  qualityFlags: TermRef[],
  methodRef?: RecordRef,
  calibrationRef?: RecordRef
}

Uncertainty {
  standardUncertainty: DecimalString,
  distribution: normal | uniform | triangular | empirical | unknown,
  coverageFactor?: DecimalString,
  coverageProbability?: DecimalString,
  degreesOfFreedom?: DecimalString,
  covarianceGroupRef?: RecordRef,
  contributors?: [{sourceRef, sensitivityCoefficient, standardUncertainty}],
  evaluationMethod: typeA | typeB | mixed | unspecified
}
```

The normative unit vocabulary is a governed UCUM-compatible subset with explicit RTracer TermRefs. Angle and information remain tagged semantic dimensions even when a pure SI reduction would call them dimensionless. Currency is never a physical dimension and uses Money plus exchange-rate records.

### 36.2 Arithmetic and comparison rules

| Operation | Precondition | Result / rejection |
| --- | --- | --- |
| add/subtract | same quantity kind or declared affine-compatible kinds; common frame/time basis | Exact decimal/rational conversion; propagate covariance; otherwise DIMENSION_OR_CONTEXT_MISMATCH |
| multiply/divide | dimension vectors and semantic-kind rule permit composition | Derived kind + dimension vector + formula receipt |
| compare | same kind, measurement location, frame, correction basis and compatible uncertainty | ordered/conflicting/indeterminate; never compare crank and wheel power directly |
| aggregate | unit-compatible observations and declared weighting/correlation | method, exclusions, window and uncertainty retained |
| differentiate/integrate | monotonic mapped time and sufficient sampling model | algorithm, boundary handling, filtering and clock uncertainty retained |
| convert | locked exact or bounded conversion rule | source always preserved; rounding mode/precision explicit |
| threshold | threshold uses same kind/context and declares inclusive/exclusive boundary | PASS/FAIL/INDETERMINATE plus margin and uncertainty rule |

```text
Uncertainty propagation profile
For z = f(x1...xn) with covariance matrix Sigma and Jacobian J:
  u(z)^2 = J * Sigma * transpose(J)

For independent multiplication z = x*y, first-order relative form:
  (u(z)/z)^2 = (u(x)/x)^2 + (u(y)/y)^2

Independence may be assumed only when the method declares it. Shared calibration,
clock, environment or source equipment creates covariance and must not be counted twice.
Monte Carlo propagation records sampler, seed, distribution versions, sample count,
convergence checks and output quantiles; a seed is reproducibility metadata, not evidence.
```

### 36.3 Frame and pose contract

```text
SE(3) frame and transform profile
FrameDefinition {
  frameId, parentFrameId?, handedness: right,
  axisDefinitions[], originDefinition, datumRef?, epoch?,
  bodyFixed: boolean, configurationId?, validInterval
}

RigidTransform {
  parentFrameId, childFrameId, validTime,
  translationM: [DecimalString x3],
  rotationQuaternionWxyz: [DecimalString x4],
  covariance6x6?: [DecimalString x36],
  sourceRefs[], interpolationPolicy, maxExtrapolationNs
}

Rules:
- quaternion norm error <= 1e-12 after decimal-to-working-precision conversion;
- canonical sign chooses the first non-zero component positive;
- composition order is parent_T_child; never inferred from field names;
- a transform cycle at one valid instant is rejected unless it closes within a
  declared tolerance and is stored as a calibration residual, not canonical topology;
- pose is inseparable from frame, configuration and valid time.
```

- Articulated machines store a kinematic tree/graph of joint definitions and time-varying joint states; a single vehicle pose cannot locate every link, wheel, wing, manipulator or trailer.

- Deformable hulls, sails, tires and soft robots reference a model/basis and state coefficients with a validity envelope; rigid transforms alone are insufficient.

- Geospatial coordinates name horizontal and vertical datum, coordinate epoch, axis order and uncertainty. A bare lat/lon/alt triple is invalid for precision claims.

- Privacy transforms such as delay, grid snap or noise produce a new GeometryProjection with a transform receipt. They never overwrite or masquerade as the source coordinate.

### 36.4 Clock domains and piecewise-affine mapping

```text
Clock mapping and uncertainty
ClockDomain {
  clockId, producerDeviceId, tickUnit, counterBits?, nominalRate,
  monotonicWithinBoot, bootId, oscillatorClass, leapBehavior
}

ClockMappingSegment {
  clockId, referenceScale, deviceTickStart, deviceTickEnd,
  t0Device, t0ReferenceSeconds, t0ReferenceNanos,
  rateRatioA, offsetSecondsB,
  covariance2x2, maxResidualNs, fitMethod, syncObservationRefs[]
}

t_reference = A * (t_device - t0Device) + B
u_time(t)^2 = [dt, 1] * Cov(A,B) * transpose([dt, 1]) + u_sync^2

Counter unwrap is valid only inside one bootId and wrap model. A reset, rate step,
GNSS reacquisition, PTP grandmaster change or residual breach closes the segment.
```

```text
UTC labels do not create simultaneity
Two channels may both print UTC while carrying different latency, synchronization, buffering and clock uncertainty. Cross-channel fusion must use ClockMappingSegment and the observation/capture time semantics of each channel.
```

### 36.5 Dyno, test, and performance equivalence

| Equivalence axis | Must match or be transformed explicitly |
| --- | --- |
| measurand | power/torque/thrust/energy kind, direction, phase and averaging definition |
| measurement location | crank, shaft, hub, wheel, roller, propeller, jet, electrical input or inferred boundary |
| configuration | exact snapshot, gearing, tire/track/propeller, control software, calibration and active limits |
| environment | temperature, pressure, humidity, altitude/density, wind/current and correction standard |
| setup | instrument/fixture model, inertia, ramp/steady profile, load, tie-down, cooling and warm-up |
| processing | sampling, filtering, smoothing, loss correction, run exclusion and uncertainty method |
| state | fuel/charge/thermal/health state, consumables, payload and operator mode |
| traceability | instrument calibration chain, raw data digest, procedure/version, personnel and review |

A PerformanceComparison record reports DIRECTLY_COMPARABLE, TRANSFORMED_COMPARABLE, CONTEXT_ONLY or NOT_COMPARABLE, names every transformation and exposes the uncertainty/margin. A chart renderer may not place unlike power locations on one unlabeled axis.

### 36.6 Numerical implementation requirements

- Canonical parsing and money use exact decimal/integer arithmetic. Binary floating point is allowed inside declared numerical algorithms but never silently written back as an exact source value.

- Every algorithm declares working precision, rounding mode, overflow/underflow behavior, missing/invalid sample handling and deterministic reduction order where golden equality is required.

- Do not use NaN payloads as domain state. Validity, saturation, sensor failure and not-observed conditions use explicit quality bits and knowledge states.

- Comparisons near a boundary declare tolerance and uncertainty behavior. A generic epsilon is forbidden across quantity kinds and scales.

- Golden vectors include signed zero rejection, subnormal inputs, counter wrap, quaternion antipodes, transform composition, unit offsets, correlated uncertainty and extreme but schema-valid magnitudes.

# 37. Telemetry, media, and high-rate evidence protocol

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.37 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:8a77f69b1f81684969191b82576473b6da97e6329654c03462d7e0be46fd7a7d

Telemetry admission preserves producer identity, boot/session boundaries, native sample identity, exact channel semantics, raw clock readings, encoded and plaintext integrity, configuration, calibration, privacy and quality. A time-series database row is a projection of this evidence, not the original evidence itself.

![Diagram showing device clock readings mapped through piecewise clock models to reference time while channel descriptors and samples are packaged into immutable segment manifests and derived metrics.](/substrate/v1.4.1/assets/media/image12.png)

Channel, clock, configuration or calibration changes close a segment instead of mutating its interpretation.

### 37.1 CaptureSession and producer boot identity

```text
Capture-session and sample identity
CaptureSession {
  captureSessionId, tenantId, producerDeviceId, producerSystemId,
  bootId, operationId?, configurationId, controllerSetDigest?,
  startedAtReceipt, declaredStartClockReading,
  firmwareDigest, softwareSetDigest, channelSetDigest,
  clockDomainRefs[], calibrationSetDigest,
  acquisitionPurposeRefs[], privacyPolicyRef, retentionClass,
  sessionState, closingReceiptRef?
}

bootId is random per producer restart and never inferred from a clock reset.
Sample identity = (producerDeviceId, bootId, channelId, sourceSequence).
The same identity with equal canonical sample bytes is a duplicate;
the same identity with different bytes is PRODUCER_EQUIVOCATION.
```

| Session state | Allowed operation | Terminal evidence |
| --- | --- | --- |
| DECLARED | negotiate channel/schema/clock/calibration locks | none |
| OPEN | reserve uploads and admit segments | none |
| DEGRADED | admit with named limitations; no silent quality recovery | degradation records |
| CLOSING | finish committed uploads and reconcile gaps | gap/completeness assessment |
| CLOSED | read/replay only | signed closing receipt and terminal ranges |
| ABORTED | isolated recovery only | reason, retained artifacts and unknown-effect ranges |

### 37.2 ChannelDescriptor 1.3

```text
Versioned signal meaning
ChannelDescriptor {
  channelId, descriptorVersion, sourceNamespace, nativeSignalName,
  phenomenonRef, featureOfInterestRef, quantityKindRef,
  datatype: i8|i16|i32|i64|u8|u16|u32|u64|f32bits|f64bits|bool|utf8|binary,
  shape: scalar|fixedVector|fixedMatrix|variableArray|struct,
  shapeParameters, byteOrder, unitRef, dimensionSignature,
  frameRef?, axisSemantics[], signConvention,
  measurementBoundaryRef?, measurementLocationRef?,
  samplingMode, nominalRateHz?, validRange?, saturationRange?,
  calibrationRef?, uncertaintyModelRef?, clockId,
  interpolationPolicy, aggregationPolicy, qualityBitRegistryDigest,
  privacyClass, retentionClass, rightsRef
}

Binary floating samples are stored as exact IEEE-754 bit patterns. Non-finite
patterns remain raw evidence but cannot become normalized QuantityValue values.
Datatype, shape, unit, frame, calibration, privacy or clock changes mint a new
descriptor version and force a segment boundary.
```

### 37.3 Sample-batch column profile

| Column | Type | Invariant |
| --- | --- | --- |
| sourceSequence | u64, delta-encoded allowed | Strictly increasing inside producer+boot+channel unless sampling mode declares sparse event IDs |
| deviceTick | u64/i64 according to ClockDomain | Raw reading retained; unwrap is a derivation |
| value | descriptor datatype/shape | No unit/frame conversion in raw batch |
| validity | bitmap | False means value bytes are not normalized data; raw bytes may remain in artifact |
| quality | u32 or u64 bitset | Registry-locked meanings; unknown bits preserved |
| uncertainty | optional scalar/vector or shared model ref | Applies to value and named confidence basis |
| receiptTimeDelta | optional signed integer ns | Transport observation only; not phenomenon time |
| sourceFlags | optional native bitset/blob | Exact producer status retained independently of normalized quality |

| Reference flag | Meaning |
| --- | --- |
| VALID | normalized value may be consumed under remaining flags |
| MISSING | sample identity/time exists but value is absent |
| UNAVAILABLE | producer cannot provide value |
| SENSOR_FAULT | source reports failed/degraded sensing |
| SATURATED / CLIPPED | physical or digital range exceeded |
| OUT_OF_RANGE | schema-valid bytes outside declared operating/measurement range |
| STALE | age exceeds consumer freshness requirement |
| CLOCK_UNSYNCHRONIZED | reference-time mapping does not meet profile |
| CALIBRATION_EXPIRED | calibration validity elapsed at observation |
| ESTIMATED / INTERPOLATED / FILTERED / DERIVED | value is not an unaltered direct sample |
| CONFLICTED | another same-scope value cannot be reconciled automatically |

### 37.4 SegmentManifest 3.0

```text
Immutable telemetry segment manifest
SegmentManifest {
  segmentId, captureSessionId, producerDeviceId, bootId,
  configurationId, operationId?, channelDescriptorLocks[],
  clockModelLocks[], calibrationLocks[],
  sequenceRanges[{channelId, first, last, sampleCount}],
  deviceTickRanges[], observedReferenceTimeRanges[],
  encodedArtifact: {digest, byteLength, mediaType, codec, codecVersion},
  plaintextArtifact: {digest, decodedByteLength, schemaDigest},
  encryptionEnvelopeDigest?, compressionDictionaryDigest?,
  rowGroupDigests[], merkleRoot?, statisticsDigest?,
  gapClaims[], qualitySummary, privacyClass, retentionClass,
  rightsRef, manifestDigest
}

Reference scalar profile closes a segment at the first of:
  60 seconds of mapped time; 64 MiB decoded; 1,000,000 rows;
  producer boot/configuration/channel/clock/calibration/privacy change;
  explicit discontinuity or session close.
Hard limits: 256 MiB encoded, 1 GiB decoded, expansion ratio 100:1.
Large image, LiDAR, sonar, simulation or mesh frames use separate bounded profiles.
```

plaintextArtifact.digest identifies decoded semantic bytes. encodedArtifact.digest verifies stored compressed/encrypted bytes. Randomized encryption can change the encoded digest without changing plaintext identity. Object-store ETag is never accepted as a cryptographic digest.

### 37.5 Streaming ingestion state machine

1. Authenticate workload and producer; authorize capture session, purpose, quota and descriptor locks before issuing a short-lived upload capability.

1. Stream-decode into bounded buffers while enforcing encoded size, decoded size, expansion ratio, nesting and row limits. Never allocate from untrusted declared sizes alone.

1. Verify encoded and plaintext digests, schema/footer integrity and row-group digests before semantic admission.

1. Resolve configuration, channel, clock, calibration, privacy and rights locks from the local registry/ledger checkpoint.

1. Validate sample identities, sequence coverage, datatype/shape, unit/dimension, clock ranges, quality encoding and finite/range policies without changing source values.

1. Classify duplicate, equivocation, gaps, overlaps, discontinuity, saturation, dropout, stale calibration and clock quality; produce a deterministic QualityAssessment.

1. Commit artifact locator, SegmentManifest, admission receipt and outbox event atomically; derived metrics run only after the source commit.

| Disposition | Meaning | Downstream permission |
| --- | --- | --- |
| REJECT | unauthorized, over limit or structurally impossible before semantic retention | safe failure receipt only |
| QUARANTINE | integrity/equivocation/malicious or uninterpretable evidence isolated | no ordinary projection/derivation |
| ACCEPT_PENDING | bytes valid but non-authorizing reference unresolved | retain; no safety, market or factual promotion |
| ACCEPT_DEGRADED | interpretable with explicit quality defects | only consumers whose policy accepts every limitation |
| ACCEPT_CONFLICTED | valid competing evidence remains | conflict-aware projections only |
| ACCEPT | all required checks pass | normal policy-bound use |

### 37.6 Media, synthetic content, and sensor fusion

- CaptureReceipt binds device/session, exact configuration, raw clock reading, approximate location/privacy class, artifact digest, encoding, capture software and custody start.

- C2PA-compatible provenance can be attached as evidence but does not replace platform rights, consent, subject resolution or factual verification.

- Synthetic, composited, enhanced and generatively extended media remain in creative/synthetic lanes. Edit lineage names source artifacts and transformations; a photorealistic output never becomes condition evidence by repetition.

- Fusion produces a DerivedObservation with exact source sample ranges/artifacts, clock/frame transforms, association hypotheses, algorithm/model digests, parameters, covariance/confidence semantics and alternatives.

- Similarity search returns candidates and calibrated scores. It cannot merge vehicle identity, assert ownership, reveal a private profile or notify an owner without a separate policy decision.

### 37.7 Derived metric contract

```text
Reproducible metric definition and result
MetricDefinition {
  metricId, version, inputPredicates[], timeAlignmentPolicy,
  gapPolicy, minimumCoverage, formulaOrModelDigest,
  outputQuantityKind, outputUnit, uncertaintyMethod,
  applicabilityEnvelopeRef, privacyPolicyRef
}

MetricResult {
  definitionRef, inputRecordIds[], exactSegmentRanges[],
  configurationId, operationId?, validTime,
  value, uncertainty, coverageFraction, qualityFlags[],
  exclusions[], computationReceiptRef, invalidationState
}

Examples:
  energy = integral(P(t) dt)
  energyIntensity = energy / distance

Irregular sampling requires a declared integration rule. Distance below a
metric-specific minimum, insufficient coverage, uncertain clock order or an
invalidated calibration produces INDETERMINATE, not a plausible number.
```

# 38. Configuration compiler, physical-model registry, and operating-envelope solver

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.38 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:34e3931d467e32e073ec764903c2d271d1362c0801f2f86045fb6649bff3eb8d

A configuration is not certified merely because its parts are listed. The compiler materializes the exact installed graph, validates ports and topology, propagates resource/control/safety paths, evaluates effectivity and operating-envelope predicates, invokes registered quantitative solvers and emits a minimal proof graph for every capability result.

![Diagram of a deterministic capability compiler consuming configuration, operational state, function authority and operating-envelope facts, then returning available, unavailable or indeterminate capability with proof.](/substrate/v1.4.1/assets/media/image13.png)

Unknown input and compiler error remain distinct; neither can authorize execution.

### 38.1 Effective graph materialization

```text
Deterministic graph compilation
compile(configurationId, contextCheckpoint, packLock):
  verify configuration, registry and pack digests
  materialize item occurrences, ports, connections, software and calibrations
  evaluate effectivity predicates using four outcomes TRUE/FALSE/UNKNOWN/ERROR
  reject duplicate exclusive occupancy and forbidden composition cycles
  validate frames, joints, geometry and configuration-specific transforms

  for each realized connection:
    unify port family, medium/carrier, direction, dimension and protocol
    intersect voltage/current/pressure/flow/speed/torque/load/range constraints
    require a non-empty operating intersection and declared protection/failure behavior

  build structural, support, energy, material, thermal, data, control,
        kinematic, safety and utility subgraphs
  identify strongly connected components; require a registered solver for each loop
  propagate source availability, conversion paths, observability, authority,
        fault overlays and environmental/resource prerequisites to a fixed point
  evaluate registered quantitative constraints and operating envelope
  emit CapabilityCompilationReceipt and minimal explanation DAG
```

| Outcome | Definition | Authorization meaning |
| --- | --- | --- |
| TRUE | all required facts established and every required solver converged inside its validity domain | may contribute to authorization; never authorizes alone |
| FALSE | at least one required condition is established false or a hard contradiction exists | capability unavailable |
| UNKNOWN | required fact absent, stale, conflicted, withheld or too uncertain | fail closed; request evidence or fallback |
| ERROR | invalid definition/input, resource limit, unsupported operator or solver non-convergence | fail closed; engineering incident |

For allOf: FALSE dominates, then ERROR, then UNKNOWN, otherwise TRUE. For anyOf: TRUE dominates, then ERROR, then UNKNOWN, otherwise FALSE. Negation maps TRUE/FALSE and preserves UNKNOWN/ERROR. Pack evaluation is stratified; recursion through negation is rejected.

### 38.2 Port and connection unification

| Constraint family | Examples | Failure code |
| --- | --- | --- |
| topological | output-to-input, source/sink, fan-out, exclusive slot, bus membership | RTR-CONFIG-TOPOLOGY |
| carrier/medium | electricity AC/DC, fuel grade, hydraulic fluid, air/water/data/protocol | RTR-CONFIG-MEDIUM |
| dimensional | voltage/current, torque/speed, pressure/flow, force/displacement | RTR-CONFIG-DIMENSION |
| range | continuous/peak limits, temperature, pressure, voltage, RPM, load and duration | RTR-CONFIG-RANGE |
| geometry | connector, shaft alignment, gauge, mounting pattern, clearance and motion envelope | RTR-CONFIG-GEOMETRY |
| timing/protocol | bus rate, message set, synchronization, latency, update and watchdog | RTR-CONFIG-PROTOCOL |
| protection | fuse/breaker/relief/guard/interlock, fault containment and disconnect | RTR-CONFIG-PROTECTION |
| authority | installer approval, software license, key/certificate, release-to-service | RTR-CONFIG-AUTHORITY |

### 38.3 CapabilityCompilationReceipt

```text
Capability result with machine-checkable explanation
CapabilityCompilationReceipt {
  compilationId, compilerVersion, compilerBinaryDigest,
  configurationId, configurationDigest, contextCheckpoint,
  registryLockDigest, domainPackLockDigest,
  requestedCapabilities[], realizedGraphDigest,
  resultByCapability[{capabilityId, outcome, limitingConstraints[],
                      proofNodeRefs[], unresolvedFacts[], marginSetRef?}],
  solverRuns[], findingCodes[], resourceUsage,
  startedAt, completedAt, outputDigest
}

ProofNode {
  nodeId, ruleOrSolverRef, outcome, inputNodeRefs[], inputRecordRefs[],
  constraintValues?, explanationTermRef, sensitiveEdgePolicy
}

The public explanation is a redacted projection of this DAG. Redaction must not
change the underlying outcome, and a non-interference test must prove hidden
facts cannot be inferred through node counts, errors or timing classes.
```

### 38.4 Physical-model registry

```text
Versioned equations and computation receipt
PhysicsModelDefinition {
  modelId, version, modelFamily, equationSetDigest,
  stateVariables[], algebraicVariables[], inputs[], disturbances[], parameters[],
  constraints[], invariants[], eventGuards[], resetMaps[],
  supportedConfigurationPredicates[], validDomainRef,
  initializationProcedureRef, solverProfile,
  verificationEvidenceRefs[], validationEvidenceRefs[]
}

ComputationRun {
  runId, modelRef, exactInputRecordIds[], inputArtifactDigests[],
  configurationId, operationId?, validTime, dataCutoff,
  parameterSetDigest, solverBinaryDigest, solverOptions,
  randomSeeds[], convergenceReport, resultArtifactDigest,
  qualityDisposition, invalidatedBy[]
}
```

| Domain family | Reference equation/model obligations |
| --- | --- |
| rigid/multibody | mass matrix, constraints/contact/friction, forces/torques, energy balance and integrator |
| road + RC | wheel/ground speed, slip low-speed policy, tire/contact, grade/wind, gearing, braking and measurement boundary |
| rail | consist/coupler forces, resistance, adhesion, brake propagation, route/gauge and signaling regime |
| marine/subsurface | 6-DOF inertia/added mass, hydrostatics, damping, current-relative speed, propulsion, buoyancy/ballast and pressure envelope |
| air + eVTOL | air-relative state, atmosphere, aerodynamic coefficients, rotor/propulsor domain, ground effect, transitions and failure cases |
| lighter-than-air | gas/air density, envelope volume/pressure/temperature, ballonet/ballast, tether, static lift and aerodynamic propulsion |
| space | frame/epoch/time scale, gravity/perturbations, mass/propellant, thrust/attitude, covariance and propagator |
| robot/manipulator | kinematics/dynamics, joint/torque/thermal limits, singularity, collision, payload inertia and tool frame |
| tethered | tension-only/slack modes, length/payout, elasticity/catenary/drag, anchor margin, conductor limits and break dynamics |
| transforming hybrid | hybrid automaton with mode invariants, guards, intermediate hazards, reset map and active equation set |

```text
Models are bounded claims
An equation can be correctly implemented and still be invalid for the current scale, Reynolds number, sea state, tire regime, propeller advance ratio, atmosphere, payload, structural mode or controller. Every output reports both numerical convergence and model applicability.
```

### 38.5 Operating-envelope predicate AST

```text
Quantitative and stateful operating envelope
EnvelopeDefinition {
  envelopeId, version, applicableConfigurationPredicates[], modes[],
  entryPredicate, continuePredicate, hardExitPredicate,
  hysteresisPolicy, entryDwell, softExitDwell,
  requiredEvidenceFreshness, requiredProbabilityOrBound,
  monitorDefinitionRef, fallbackRef
}

Predicate := allOf | anyOf | not |
  compare(quantity, operator, threshold, uncertaintyPolicy) |
  within(value, interval) | rateWithin(value, interval) |
  geofence | routeSegment | modeIs | configurationHas |
  resourceRemaining | healthState | linkQuality |
  modelValidatedFor | customRegistered

For constraint g_i(x,c) <= 0:
  inside only when the declared uncertainty rule is satisfied.
  probabilistic profile: P(g_i <= 0) >= p_required.
  bounded profile: entire interval inside entry bound => TRUE;
                   entire interval outside exit bound => FALSE;
                   otherwise UNKNOWN.
```

- Hard exit triggers immediately. Soft exit respects declared dwell. Entry uses stricter boundaries than continuation to prevent chatter.

- Monitor output includes current outcome, normalized margin per constraint, limiting constraint, uncertainty, predicted time-to-exit, fallback deadline and source checkpoint.

- Unknown is handled per constraint policy but cannot be silently treated as inside for a safety-critical capability.

- Road friction/visibility, rail authority/braking, under-keel clearance/sea state, blimp lift/wind, submarine pressure/energy, robot workspace/collision, tether tension/anchor and spacecraft power/thermal/ephemeris all use the same predicate machinery with domain-specific terms.

### 38.6 Digital-twin state and confidence vector

```text
Digital twin as an evidence-qualified estimate
TwinStateEstimate {
  twinId, physicalAssetId, configurationId,
  stateVectorDefinitionRef, estimateArtifactDigest,
  covarianceOrEnsembleArtifactDigest, observedAt, dataCutoff,
  estimatorDefinitionRef, modelDefinitionRef, parameterSetDigest,
  inputSegmentRefs[], latencyNs, unobservableStates[],
  divergenceTests[], applicabilityState, modelState
}

modelState in {
  UNVERIFIED, VERIFIED, CALIBRATED, VALIDATED_IN_DOMAIN,
  MONITORED, OUT_OF_DOMAIN, DIVERGED, INVALIDATED
}

Confidence is a vector, never one percentage:
  implementation verification; convergence; parameter identifiability;
  calibration recency; validation-domain coverage; input quality;
  observability; model-form uncertainty; domain proximity;
  clock freshness; divergence status.
```

# 39. Control authority, command fencing, handover, and safety-runtime isolation

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.39 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:c9271e79961a76fb44f3fc1058c975af9814491990b93ed0a7b14ed02816f3b2

The profile/social agent can describe a drive, book an event or propose a mission. It cannot become a motion controller. Safety-critical execution uses a separately deployed control plane with hardware-rooted workload/device identity, function-scoped leases, monotonic authority epochs, bounded command envelopes, independent supervision and asset-specific minimum-risk behavior.

![Diagram separating workload identity, policy decisions, agent and commerce proposals, and physical control into isolated trust planes.](/substrate/v1.4.1/assets/media/image14.png)

Identity proves who is speaking; policy grants what may be done; only the control plane can actuate.

### 39.1 Function-scoped authority lease

```text
Monotonic, reboot-safe control ownership v1.4
AuthorityClockRef {
  arbiterId, clockId, arbiterBootId, tickRate,
  authorityEpoch, antiRollbackStateDigest
}

AuthorityLease {
  leaseId, assetId, configurationDigest, functionId,
  controllerPrincipalId, controllerWorkloadIdentity,
  authorityClockRef, priorityClass, mode, allowedCommandKinds[],
  operatingEnvelopeRef, safetyConstraintRef,
  validFromTick, expiresAtTick, maxCommandRate,
  heartbeatPeriodTicks, missedHeartbeatLimit,
  predecessorLeaseId?, handoverTransactionId?, revocationChannel,
  issuerDecisionRef, leaseDigest, issuerProofRef
}

Arbiter reboot changes arbiterBootId and increments persisted authorityEpoch
before arming. Anti-rollback failure latches SAFE and invalidates old leases.
AuthorityLease {
  leaseId, assetId, configurationDigest, functionId,
  controllerPrincipalId, controllerWorkloadIdentity,
  authorityEpoch, priorityClass, mode, allowedCommandKinds[],
  operatingEnvelopeRef, safetyConstraintRef,
  validFromMonotonic, expiresAtMonotonic,
  maxCommandRate, heartbeatPeriod, missedHeartbeatLimit,
  predecessorLeaseId?, handoverTransactionId?, revocationChannel,
  issuerDecisionRef, leaseDigest, issuerProofRef
}

The arbiter stores current authorityEpoch per function in safety-grade local
state. A command under an older or future epoch is rejected before it reaches
an actuator. Wall-clock timestamps do not fence controllers.
```

### 39.2 ControlCommand and disposition

```text
Fenced, framed, expiring control command v1.4
ControlCommand {
  profile, commandId, controllerId, controllerBootId,
  authorityClockRef, leaseId, authorityEpoch,
  commandSequence, sequencePolicy, functionId, targetSelector,
  setpointOrAction, frameRef, envelopeRef,
  issuedTick, expiresTick, commandDigest, controllerProofRef
}

CommandDisposition {
  commandId, commandDigest, admissionResult, admissionReasonCodes[],
  admittedAtTick?, executionState, executionEvidenceRefs[],
  finalAtTick?, dispositionDigest, arbiterProofRef
}

Exact duplicate ID/sequence/digest returns the original disposition without
actuator re-entry. Same ID or sequence with different digest is equivocation and
fences the controller. Admission and physical execution outcomes remain distinct.
ControlCommand {
  commandId, assetId, functionId, controllerId,
  leaseId, authorityEpoch, sequence,
  configurationDigest, controlMode,
  setpoint: QuantityValue | Pose | Trajectory | DiscreteCommand,
  setpointFrameRef?, issuedAtMonotonic, validFromMonotonic,
  expiresAtMonotonic, rateLimits?, safetyConstraintRef,
  expectedAckDeadline, commandDigest, controllerProof
}

CommandDisposition {
  commandId, outcome: accepted|rejected|superseded|expired|partiallyApplied,
  reasonCode, receivedAtMonotonic, appliedAtMonotonic?,
  appliedSetpoint?, actuatorFeedbackRefs[], supervisorInterventionRef?
}
```

- Setpoint units, quantity kind, frame, configuration, mode and sequence must match the active function contract. The arbiter never guesses or converts an omitted frame.

- Expiration is checked on a safety-local monotonic clock. A stale network packet cannot become valid because a wall clock moved backward.

- Every accepted command produces actuator/plant feedback or a timeout disposition. Accepted does not mean the requested physical effect occurred.

- Command and feedback telemetry use a high-integrity lane separate from social, market, profile and advertisement events.

### 39.3 Deterministic arbitration precedence

| Precedence | Authority | Behavior |
| --- | --- | --- |
| 1 | hardware/protective boundary | Physical interlock, fuse, relief, watchdog or certified limiter cannot be overridden by software |
| 2 | emergency-stop authority | Immediate safe transition using independent path where required |
| 3 | safety veto/limit controller | Rejects or reshapes commands inside validated constraint set |
| 4 | current function lease | Only matching controller/epoch/sequence may command |
| 5 | registered shared-control policy | Combines compatible variables through one locked blending equation |
| 6 | fallback controller | Activates when handover/link/health/envelope conditions require |

Shared blending is legal only for the same physical variable, compatible units/frame/timebase, a registered blend, and preserved actuator/safety limits. Otherwise simultaneous commands are a conflict and invoke the named fallback rather than an average.

### 39.4 Two-phase handover protocol

1. PREPARE — current controller/arbiter proposes exact function set, reason, state checkpoint and desired barrier.

1. READY — candidate proves workload health, configuration, context, link, clock, model/envelope readiness and synchronized command state.

1. COMMIT — arbiter atomically increments authorityEpoch, issues the new lease and records the handover barrier.

1. FENCE — old epoch becomes invalid for every command at or after the barrier; delayed packets remain rejected.

1. ACTIVATE — new controller sends its first command and receives an accepted disposition within the declared deadline.

1. COMPLETE — actuator/plant feedback confirms control; otherwise timeout invokes the function-specific fallback.

### 39.5 Safety-state machine

```text
Reference safety-runtime transitions
DISABLED -> SAFE -> STANDBY -> ARMED -> ACTIVE
ACTIVE -> DEGRADED -> FALLBACK -> SAFE
ACTIVE -> SAFE (normal disarm only under permitted transition)

ANY OPERATIONAL STATE -> EMERGENCY_STOP
EMERGENCY_STOP -> RECOVERY_CHECK -> SAFE
FAULT_LATCHED -> RECOVERY_CHECK -> SAFE

Forbidden:
  EMERGENCY_STOP -> ACTIVE
  FAULT_LATCHED -> ARMED/ACTIVE
  DEGRADED -> ACTIVE without recovery predicates
  SAFE -> ACTIVE without STANDBY and ARMED gates

Every transition binds source condition, configuration, authority epoch,
monitor snapshot, action taken, deadline, feedback and receipt.
```

```text
Minimum risk is domain-specific
Loss of link does not universally mean stop. A road vehicle may pull over; a boat may hold, anchor or surface; an aircraft may loiter, return or land; a blimp may preserve altitude and navigate to recovery; a spacecraft may enter safe pointing; a robot may hold load or release energy. The fallback is an installed, verified and locally executable capability.
```

### 39.6 Safety filter and independent supervisor

```text
Illustrative constrained safety filter - not universal certification
u_safe = argmin_u ||u - u_requested||_W^2
subject to:
  actuator position/rate/effort/thermal constraints
  operating-envelope constraints
  collision/separation/structural/stability constraints
  control-barrier condition: dh/dt + alpha(h(x)) >= 0

SafetyFilterDefinition binds:
  state estimate inputs; model/constraint digests; solver/profile;
  validated operating domain; maximum solve time; infeasibility response;
  numerical tolerance; fallback command; verification/validation evidence.

Independent supervisor checks command freshness, lease epoch, watchdog,
critical sensors, actuator agreement, envelope and heartbeat. It can veto or
transition safe state without relying on the primary controller or cloud.
```

### 39.7 Control software release and evidence

| Gate | Required artifact |
| --- | --- |
| requirements/hazard | function safety requirements, hazard analysis, assumptions, ODD/envelope and fallback |
| implementation | source/build provenance, binary digest, compiler/toolchain, dependencies and configuration/calibration schema |
| verification | unit/property/static/fuzz tests, numerical vectors, timing/WCET and fault-injection results |
| simulation | scenario/model corpus, coverage, model limitations and differential results |
| hardware-in-loop | exact controller/actuator/sensor versions, timing/network impairments and pass/fail evidence |
| vehicle release | installed configuration, calibration, checks, approver, permitted envelope and rollback version |
| operations | health/heartbeat, anomaly thresholds, incident response, rollback/disable and audit retention |

# 40. Vehicle-native agent, persona, memory, content, and tool runtime

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.40 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:051abf4575c5ad330115010713bf3d012ab8c9ec01efc523df7454b6023ba5ca

The vehicle may speak in first person, build an audience and operate a brand while the platform keeps fiction, factual claims, legal agency, economic benefit and physical control distinct. The language model is an untrusted probabilistic drafting component inside a deterministic context, policy, claim-checking and action-transaction shell.

### 40.1 Five identities that must remain separate

| Object | Examples | May do |
| --- | --- | --- |
| Vehicle entity | KUN physical truck and configuration history | Be subject of records, media, telemetry, profile and market objects |
| Persona | KUN ‘Prague Workhorse’ voice/canon/version | Generate licensed representation under rights and disclosure policy |
| Agent runtime | deployed planner/model/tool orchestrator | Retrieve, draft and propose within grants; never own rights or money |
| Principal | owner, custodian, team member, organization or service | Authenticate, grant, approve, revoke and accept accountability |
| Beneficiary/legal account holder | person or organization receiving economic benefit/obligation | Hold funds, tax duties, title/custody and contract obligations |

### 40.2 PersonaVersion and representation grant

```text
Versioned character and licensed voice
PersonaVersion {
  personaId, version, representedVehicleId,
  displayName, biography, languageProfiles[], toneConstraints[],
  factualVoicePolicy, fictionMarkers[], canonRecordRefs[],
  prohibitedClaims[], visualIdentityRefs[], voiceModelRefs[],
  safetyDisclosures[], audiencePolicies[],
  predecessorVersion?, activationDecisionRef, contentDigest
}

RepresentationGrant {
  grantId, grantorPrincipalId, personaId, agentId?,
  allowedSurfaces[], allowedContentKinds[], allowedLanguages[],
  commercialUse, sponsorCategories[], disclosureDuties[],
  reviewThresholds[], territory?, validInterval,
  revocationEpoch, succession/transferPolicy, rightsEvidenceRefs[]
}

Vehicle transfer does not automatically transfer the persona, voice model,
followers, sponsorship, archive, media licenses or representation grant.
```

### 40.3 Context assembly and memory classes

| Memory class | Source of truth | Prompt treatment |
| --- | --- | --- |
| factual dossier | policy-filtered records/evidence at exact checkpoint | read-only citations; each fact carries record IDs and epistemic state |
| persona canon | approved PersonaVersion/canon records | may control style/fiction but cannot override facts or policy |
| conversation | session-scoped messages and consented preferences | untrusted user content; expiry and participant scope |
| creative scratch | model drafts and planning artifacts | non-evidence; delete on expiry; never retrieved as fact |
| action state | ActionProposal/Decision/Receipt records | deterministic structured objects; not editable natural-language memory |
| external retrieval | web, comments, documents, sponsor/event feeds | hostile evidence lane; content cannot provide instructions or credentials |

```text
Deterministic context boundary around the model
AgentContextManifest {
  contextId, agentId, personaVersion, principalId, purpose,
  audience, requestedTask, validAt, knownAt,
  policyDigest, registryLockDigest, projectionCheckpoint,
  retrievedItems[{itemId, sourceClass, recordOrArtifactRef,
                  digest, disclosureClass, trustLane, tokenRange}],
  toolCatalogDigest, actionGrantRefs[], budgetRef?,
  redactionReceiptRefs[], contextDigest, expiresAt
}

Only the manifest builder can read credentials or policy internals. The model
receives capability handles and redacted context, never raw bearer tokens,
private keys, unrestricted precise location or hidden source fields.
```

### 40.4 Prompt-injection and untrusted-content isolation

- System policy, tool schema and grants are loaded from signed local bundles outside model-visible content. Retrieved text cannot create, edit or reprioritize them.

- Every retrieved item is delimited, source-labeled and treated as data. Instructions inside telemetry labels, service notes, image OCR, webpages, comments or PDFs have zero control authority.

- Tools accept typed canonical arguments, not shell strings or model-selected URLs/credentials. The action gateway independently validates every argument and grant.

- Secrets are referenced by opaque connector handles resolved after authorization. They never enter the prompt, model logs, traces, content drafts or error messages.

- The model cannot directly call network, filesystem, database, broker or control-plane interfaces. All effects pass through named tool adapters and ActionProposal.

- High-risk policy is fail-closed when the policy engine, grounding checker, rights service, confirmation service or reconciliation service is unavailable.

- Adversarial canaries verify that content cannot exfiltrate hidden identifiers, precise location, contact data, bidder information or credentials through prose, encoding, images or tool arguments.

### 40.5 Grounded content compiler

```text
Facts can be lively without becoming fabricated
compile_content(request):
  1. authorize purpose, audience, surface and persona version
  2. build AgentContextManifest at a fixed checkpoint
  3. generate DraftArtifact in a no-tool sandbox
  4. parse draft into atomic ClaimCandidate objects
  5. for each candidate:
       classify factual | creative-canon | opinion/affect | promotional | command-like
       factual => require GroundingEdge to exact records/evidence and epistemic label
       creative => require active persona/canon permission and fiction boundary
       promotional => require campaign/sponsor rights and disclosure
       command-like => render only as inert quoted text; no route to actuators
  6. enforce people/plate/location/media rights and audience privacy
  7. run contradiction, unsupported-superlative and stale-data checks
  8. obtain required approval for risk/surface
  9. publish exact approved bytes; produce PublicationReceipt and provenance

Any post-edit after approval invalidates the approval digest and returns to step 5.
```

| Claim class | Required attachment | Presentation rule |
| --- | --- | --- |
| observed fact | observation/evidence IDs + method/quality | state time/configuration and uncertainty where material |
| asserted history | issuer assertion/interview + attribution | say who says it; do not present as measured truth |
| derived metric | definition, inputs, algorithm, checkpoint and quality | include basis; recompute on invalidation |
| creative persona | PersonaVersion/canon permission | clearly expressive; cannot certify condition, title or safety |
| sponsored claim | campaign, consideration and evidence/rights | prominent paid/promotional disclosure |
| availability/price | fresh provider/market object and timestamp | identify quote/listing/bid/settled value precisely |

### 40.6 Content lifecycle and correction

```text
Vehicle-native publication transaction
REQUESTED -> CONTEXT_LOCKED -> DRAFTED -> CLAIM_PARSED
  -> GROUNDED -> RIGHTS_CHECKED -> APPROVED -> SCHEDULED
  -> PUBLISHED -> MONITORED

Branches:
  any pre-publication state -> REJECTED | EXPIRED
  PUBLISHED -> CORRECTION_PENDING -> CORRECTED
  PUBLISHED -> WITHDRAWAL_PENDING -> WITHDRAWN
  PUBLISHED -> RIGHTS_RESTRICTED (projection removed; audit retained)

PublicationReceipt binds exact bytes/media digest, persona version, grounding
map, rights/policy decisions, approvals, surface/provider receipt, publish time,
audience, sponsorship disclosure and correction lineage.
```

### 40.7 Tool and action proposal boundary

```text
Natural language ends before external effect
ActionProposal {
  actionId, agentId, personaVersion?, requestingPrincipalId,
  beneficiaryId, actionKind, canonicalParameters,
  parameterDigest, expectedEffects[], riskTier,
  requestedProvider, requiredResources[],
  evidenceCheckpoint, rightsRefs[], budgetRef?,
  explanation, createdAt, expiresAt
}

The proposal is inert. Policy evaluation, exact confirmation, reservation,
provider dispatch, reconciliation, settlement and final receipt occur outside
the language model. The model cannot mark its own proposal approved or settled.
```

### 40.8 Voice, image, and character rendering

- A vehicle voice model has a model digest, training/input rights, language/style scope, safety disclosures, expiration and replacement/succession policy.

- Rendered speech retains transcript, pronunciation/translation transform, voice model, persona version, factual grounding map and publication receipt.

- Generated character images retain prompt/context digest, source asset rights, model/version, edits, synthetic disclosure and C2PA-compatible provenance where supported.

- No generated likeness of an identifiable person, license plate, private place or copyrighted character is assumed permitted merely because a model can render it.

- A partnership with a film/vehicle franchise uses explicit character and media licenses; the vehicle's real dossier and branded fictional representation remain distinct objects.

### 40.9 Social federation and follower portability

An ActivityPub-compatible adapter may federate public vehicle posts, follows and reactions, but it is a projection gateway rather than the canonical ledger. Federated object IDs do not become vehicle IDs; deletes/updates map to platform publication/correction/withdrawal records; remote content is untrusted; and private telemetry, identifiers, bids, grants and action events never enter the public federation stream.

| Federated object | RTracer mapping | Boundary |
| --- | --- | --- |
| Actor | public VehiclePersonaProjection | no owner/person identity or action grant implied |
| Create/Note | PublicationProjection | exact public bytes only; grounding remains local or cited safely |
| Follow | FollowerRelationship | audience relationship; no access to non-public dossier |
| Like/Announce | ReactionProjection | rate/abuse controls; never market bid or appraisal |
| Update/Delete | correction/withdrawal projection | canonical publication receipts remain append-only |
| inbox payload | quarantined untrusted external content | cannot invoke tools, policy, memory promotion or vehicle control |

# 41. Identity, authorization, privacy, and adversarial-security runtime

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.41 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:123d2099b981af83973b4b49966b7d14511455170c7e327c7aba5247aab29c4f

The vehicle may speak in the first person, but it is not thereby a human, legal person, account holder, credential, beneficiary or source of authority. Authentication proves control of a credential by a principal. Authorization proves that a current principal or workload may perform one exact action for one purpose over one exact resource set. Evidence about a vehicle never substitutes for either step.

```text
Unbreakable identity boundary
VIN, registration plate, serial, transponder, MAC address, image match, physical proximity, profile administration, follower count and persona continuity never authenticate a human or prove ownership, custody, sale authority, publication authority, spending authority or control authority.
```

### 41.1 Seven isolated trust planes

| Plane | May do | Must never do |
| --- | --- | --- |
| identity + credentials | authenticate human, organization, device, workload and provider principals | infer authority from asset identifiers, persona or proximity |
| evidence + lifecycle | admit signed records, telemetry, media, configuration and source assertions | mint grants or execute external effects |
| policy decision | evaluate grants, relationships, rights, purpose, context, risk and duties | hold provider secrets or dispatch tools |
| vehicle agent | retrieve filtered evidence, converse, draft content and propose typed actions | read unfiltered stores, possess secrets or create authority |
| tool + connector broker | render one approved proposal into one allowlisted provider request | accept arbitrary URL, code, shell, SQL or natural-language tool instructions |
| market + accounting | serialize bids, reservations, milestones, journals and reconciliation | claim legal title, escrow status or tax treatment without attributed external authority |
| safety control | operate certified steering, propulsion, braking, flight or hazardous functions | share schemas, credentials, network routes or leases with the social/commerce agent |

Every cross-plane request produces an immutable receipt naming authenticated actor, workload, exact input digest, policy or safety decision, output digest, time and failure disposition. Co-location in one tenant, process, cluster or corporate group creates no ambient trust.

### 41.2 Principal, agent, credential, and session records

```text
Canonical authentication objects
Principal {
  principalId: UUIDv4, tenantId: UUIDv4,
  kind: HUMAN|ORGANIZATION|WORKLOAD|DEVICE|PROVIDER,
  status: PENDING|ACTIVE|SUSPENDED|RECOVERY_LOCKED|RETIRED,
  assurancePolicyRef, keySetId, recoveryPolicyRef,
  legalIdentityRef?, jurisdictionRefs[], principalEpoch, createdAt
}

AgentInstance {
  agentInstanceId: UUIDv4, workloadPrincipalId,
  representedPersonaIds[], modelRuntimeRef, skillManifestDigest,
  deploymentDigest, maximumRiskTier, validInterval, status
}

CredentialBinding {
  credentialBindingId, principalId,
  kind: WEBAUTHN|MTLS|DPOP_KEY|DEVICE_KEY|RECOVERY_KEY,
  publicKeyThumbprint, algorithmSuite, authenticatorClass,
  hardwareBacked, userVerificationRequired, attestationRef?,
  keyEpoch, validInterval,
  status: ACTIVE|ROTATED|REVOKED|COMPROMISED|EXPIRED,
  compromiseEffectiveAt?
}

AuthenticatedContext {
  authenticationContextId, principalId, credentialBindingId, sessionId,
  authenticatedAt, authenticationAgeSeconds, assuranceLevel,
  userPresence, userVerification, devicePrincipalId?, workloadPrincipalId?,
  audience, channelBindingRef?, networkRiskClass, expiresAt
}
```

- Human R3/R4 actions require phishing-resistant step-up authentication. R4 recovery, sale authority and rights transfer require a predeclared second approver or recovery quorum where policy demands it.

- Workloads use short-lived asymmetric credentials and sender-constrained, audience-restricted tokens. Long-lived bearer tokens never enter prompts, URLs, logs, media processors or agent memory.

- An external verifiable credential remains an issuer assertion until issuer trust, schema, status, scope, freshness, subject binding and policy are evaluated. It never automatically becomes an internal grant.

- Key compromise appends CredentialCompromise and advances relevant credential/principal epochs. Historical signatures remain byte-verifiable, while their trust interpretation is recomputed for the compromise interval.

- Session, credential, principal, grant, persona and mandate epochs are independent. A cache key for a positive decision includes every relevant epoch.

### 41.3 Explicit relationship and capability authority

```text
Relationship and grant records
RelationshipEdge {
  relationshipId, subjectId, predicate, objectId, issuerPrincipalId,
  authorityBasisRefs[], scopeSelectors[], validInterval, recordedAt,
  relationshipEpoch, status: ACTIVE|REVOKED|EXPIRED|DISPUTED, proofRefs[]
}

Privileged predicates are a closed registry:
  owns_title_interest_in  has_custody_of  may_operate  may_maintain
  may_publish_for         may_manage_profile  may_list_for_sale
  may_accept_offer        may_transfer_right  may_spend_for
  is_beneficiary_of       may_review_content  may_review_candidate
  may_subdelegate

CapabilityGrant {
  grantId, issuerPrincipalId, granteePrincipalId, granteeAgentInstanceId?,
  delegatorGrantId?, authorityBasisRefs[], actions[], resourceSelectors[],
  fieldSelectors[], effectClasses[], providerAllowlist[], purposeSet[],
  audienceSet[], channelSet[], jurisdictionSet[], dataClassCeiling,
  locationPrecisionCeiling?, monetaryConstraints?, countAndRateConstraints?,
  contextualConstraints[], confirmationPolicyRef, obligations[],
  prohibitions[], retentionRuleRefs[], delegationPolicy,
  validInterval, grantEpoch, principalEpoch, personaEpoch?, nonce, proofRefs[]
}
```

| Selector | Exact semantics |
| --- | --- |
| ExactResourceSelector | closed resource ID set; order canonicalized as a schema-declared set |
| FieldSetSelector | schema lock + resource IDs + allowed field paths; child fields are not implicit |
| RelationshipSelector | root + allowlisted predicate path + maximum depth + graph checkpoint |
| CollectionSelector | collection ID + immutable filter digest; no mutable saved-search alias |
| ProviderResourceSelector | connector ID + exact provider resource IDs and tenant/account binding |

Ownership implies no other predicate. Profile administration does not imply sale authority. Follower, spotter, maintainer, passenger, driver and telemetry-contributor edges create no commercial authority. ReBAC paths use only explicit active edges from trusted issuers, bind a graph checkpoint, reject cycles/ambiguity and never traverse inferred, creative, recommendation or social edges. Delegation can only reduce action, resource, purpose, audience, time, money, rate, geography and further-delegation depth.

### 41.4 Deterministic policy decision and enforcement

```text
Fail-closed ABAC/ReBAC evaluation
decide(request):
  require schema_valid(request) and digest(request.proposal)==request.proposalDigest
  auth = verify_transport_and_session(request.transportProof)
  require auth.current and auth.audience == this_service
  require auth.principalEpoch == currentPrincipalEpoch(auth.principalId)

  effects = classify_effects(request.proposal)
  risk = aggregate_risk(effects, amount, audience, disclosure, repetition)
  if PHYSICAL_ACTUATION in effects: DENY("social-plane-actuation")

  attrs = resolve_at(validAt=request.validAt, knownAt=now,
                     relationshipCheckpoint=currentGraphCheckpoint,
                     evidenceCheckpoint=request.evidenceCheckpoint)
  if required attribute missing, stale, conflicted or disputed: DENY

  grants = verify_authority_chains_and_attenuation(request, attrs)
  if any hard prohibition, incident, safety, court, legal-hold,
     rights, consent or revocation denial applies: DENY
  if no explicit grant contains exact action/resources/purpose/context: DENY

  duties = union_required_duties(grants, rights, consent, risk)
  if duties conflict or cannot be enforced: DENY
  if confirmation required and exact unconsumed challenge is absent: CHALLENGE
  reservation = atomically_reserve_budget_rate_inventory(request)
  if reservation fails: DENY

  return PERMIT_WITH_DUTIES(
    proposalDigest, policyDigest, all epochs, both checkpoints,
    grantIds, dutySet, reservationId, expiresAt, oneTimeDispatchNonce)

Before connector dispatch, repeat the decision against current terms, amount,
counterparty, beneficiary, grants, epochs, incident state, confirmation and
reservation. INDETERMINATE is enforced as DENY. Explicit deny overrides permit.
```

| Risk | Representative effect | Minimum gate |
| --- | --- | --- |
| R0 | public read or policy-filtered summary | public/authenticated projection; no external effect |
| R1 | private draft, preference or internal analysis | current grant and reversible storage |
| R2 | public post, message, free invitation or reservation | grounding, rights/privacy, rate limit, receipt and reversal path |
| R3 | payment, binding booking, bid, refund or paid campaign | exact-terms confirmation, step-up, atomic mandate reservation, idempotent connector |
| R4 | sale/title representation, persona/voice transfer, sensitive disclosure or recruitment submission | designated approver/dual control, rights review, one-time confirmation and dispute bundle |
| R5 | steering, propulsion, braking, flight, payload release or hazardous actuation | structurally unavailable to social/commerce runtime |

### 41.5 Consent, legal basis, rights, retention, and disclosure

```text
Permission types remain independent
DataUseDeclaration {
  controllerPrincipalId, processorPrincipalIds[], dataSubjectRefs[],
  dataCategorySelectors[], sourceSelectors[], operations[], purposes[],
  recipientClasses[], modelTrainingUse, automatedDecisionUse,
  jurisdictions[], noticeVersion, retentionScheduleRef, securityProfileRef
}

ConsentGrant {
  dataSubjectPrincipalId, controllerPrincipalId, declarationId,
  acceptedPurposes[], acceptedOperations[], acceptedDataSelectors[],
  acceptedRecipientClasses[], affirmativeActionRef, noticeArtifactDigest,
  presentedLanguage, acceptedAt, validInterval, consentEpoch, status
}

RightsGrant {
  rightsholderPrincipalId, granteePrincipalId, assetOrWorkIds[],
  rightKinds[], permittedUses[], prohibitedUses[], territory[], language[],
  channel[], audience[], derivativePolicy, trainingPolicy,
  sublicensingPolicy, approvalPolicy, compensationRef?, validInterval
}

DisclosureReceipt {
  recipientPrincipalOrClass, dataSubjectRefs[], sourceRecordIds[],
  exactProjectionDigest, fieldsReleased[], fieldsRedacted[], purpose,
  legalBasisOrConsentRefs[], rightsGrantRefs[], jurisdiction,
  recipientDuties[], retentionAfterDisclosure, channel,
  transportProofRef, policyDecisionId, disclosedAt
}
```

Consent follows DRAFT → PRESENTED → ACCEPTED → ACTIVE → WITHDRAWN | EXPIRED | SUPERSEDED; PRESENTED may become DECLINED. WITHDRAWN is terminal and renewed consent creates a new record. Withdrawal stops new dependent processing, invalidates grants/caches, freezes scheduled content and campaigns, stops dependent analytics/training, traces derivatives, applies jurisdiction-specific remediation and emits a withdrawal-effect receipt.

```text
Retention interval computation
earliestPermittedDeletion = max(all applicable minimum-retain bounds)
latestRequiredDeletion     = min(all applicable delete-no-later bounds)

If earliestPermittedDeletion > latestRequiredDeletion and no exact scoped hold
resolves the conflict, enter COMPLIANCE_CONFLICT. A legal hold names subjects,
record classes, interval, issuer, authority, reason, review date and expiry.
```

- Authorization applies at field, relationship, aggregation and inference level. Removing a field is insufficient if counts, timing, ranking, errors or model outputs reveal the protected fact.

- Public and unauthorized projections pass non-interference tests: adding a private asset or record must not alter counts, ordering, latency class, status codes, cache keys or error wording visible to the observer.

- Envelope encryption binds tenant, object, key epoch and algorithm suite. Key destruction is an operational mechanism, not a substitute for deletion records, derivative remediation or provider disclosure duties.

- Audit access is separately authorized, minimized and logged. Hashes of low-entropy personal identifiers are still personal/pseudonymous data and are not published as transparency artifacts.

### 41.6 Prompt injection, connector, and parser containment

```text
Typed tool broker and connector manifest
ConnectorManifest {
  connectorId, version, providerPrincipalId, supportedActionKinds[],
  maximumRiskTier, requestSchemaDigestByAction{}, responseSchemaDigestByAction{},
  registeredOrigins[], serviceIdentityProfile, inboundWebhookSignatureProfile?,
  credentialVaultRef, providerIdempotencyClass: STRONG|QUERYABLE|NON_IDEMPOTENT,
  statusQueryProfile?, compensationProfiles[], retryPolicy, timeoutPolicy,
  ratePolicy, dataDisclosureProfile, egressAllowlist, sandboxProfile,
  manifestDigest, approverIds[], status
}

Model outputs are restricted to NarrativeDraft, MemoryProposal or ActionProposal.
They cannot call HTTP, browser, shell, SQL, filesystem, broker or generic messaging.
The broker validates a typed proposal and deterministically renders one registered
provider request. NON_IDEMPOTENT connectors cannot autonomously execute R3/R4.
```

- Signed system policy and signed tool schemas are outside model-visible content. Retrieved evidence, sponsor copy, service notes, OCR, comments and webpages remain untrusted inert data.

- The model sees no cookies, API keys, signing keys, payment credentials or unrestricted network client. Connector secrets resolve from opaque handles only after authorization.

- Remote fetch uses origin allowlists, DNS/IP revalidation, redirect limits, MIME verification, byte/time limits and SSRF protection. Archives and media parsers enforce recursion, decompression, memory, pixel, duration and file-count budgets.

- Webhook admission verifies provider identity/signature, replay window, event ID, raw artifact custody, schema and idempotency before producing a provider assertion.

- Injection classifiers are detection signals, not the boundary. The deterministic post-model enforcement point remains authoritative even when every classifier reports safe.

### 41.7 Spotting, advertising, and recruitment abuse controls

| Surface | Default technical controls | Forbidden inference/effect |
| --- | --- | --- |
| spotting | private precise location; delay/coarsen; strip EXIF; inspect faces/plates/minors/background; aggregate anti-triangulation; opaque invitation | live tracking, home/storage route disclosure, identity merge, public suppression oracle |
| advertising | contextual public vehicle facts or declared preferences; audience floor; precision ceiling; frequency cap; sponsor disclosure | raw route/telemetry export, sensitive human traits, insurance/employment/credit targeting, minors, undisclosed persona speech |
| recruitment | separate candidate domain; explicit evidence grant; named reviewers; human decision; short retention; decision receipt | follower rank, spend, private telemetry/location or inferred protected traits as selection features |

A spotting moves RECEIVED → QUARANTINED → SAFETY_CLASSIFIED → REDACTED → CANDIDATE_MATCHED → OWNER_REVIEW → PUBLISHED_DELAYED | PRIVATE_ONLY | DENIED. Repeated coarse observations are evaluated together. A suppressed/high-risk vehicle returns the same generic reporter response as an unmatched candidate. Candidate resolution never merges identity or asserts ownership.

### 41.8 Tamper evidence, incidents, and dispute bundles

```text
Attributable action evidence—without absolute legal claims
AuditEvent {
  auditEventId, tenantId, actorPrincipalId, agentInstanceId?,
  credentialBindingId?, authenticationContextId?, actionKind, resourceIds[],
  proposalDigest?, beforeStateDigest?, afterStateDigest?, policyDecisionId?,
  grantIds[], confirmationArtifactId?, connectorOperationId?, providerReceiptIds[],
  outcome, failureCode?, occurredAt, recordedAt, clockUncertainty,
  correlationId, traceId, previousAuditDigest, auditDigest, proofRefs[]
}

TransparencyCheckpoint {
  checkpointId, tenantOrShard, firstSequence, lastSequence, merkleRoot,
  previousCheckpointDigest, signerKeyId, signedAt,
  independentWitnessReceipts[], storageRetentionRef
}
```

| Incident | Immediate containment | Durable recovery evidence |
| --- | --- | --- |
| credential/key compromise | revoke, advance epochs, stop affected dispatch | compromise interval, affected proof set, re-evaluation and replacement credentials |
| tenant disclosure | disable projection/export path; preserve volatile evidence | exact records/recipients, disclosure receipts, notifications and corrective policy |
| connector compromise | disable manifest/version and credentials; hold unknown effects | provider reconciliation, rotated identity, reviewed compensations |
| ledger/checkpoint mismatch | freeze affected shard writes/projections | byte-level verification, witness roots, restore comparison and tamper finding |
| model/prompt compromise | disable runtime/skill digest and scheduled content | context manifests, candidate outputs, policy results and publication corrections |
| location abuse | increase delay/coarsening; freeze involved accounts | correlation graph, affected sightings, victim support and policy update |

An R3/R4 dispute bundle exports canonical records, schema/vocabulary locks, policy versions, grant chains, authentication and confirmation artifacts, provider receipts, journal batches, checkpoints/inclusion proofs and offline verification instructions. Cryptographic evidence supports attribution and dispute resolution; its legal effect remains jurisdiction- and procedure-dependent.

# 42. Auction, settlement, accounting, mandate, and transfer engine

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.42 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:8774d24c16614e303774b41419f58aa509066efd5ff53af270633220e87034b9

The social profile can display a live commercial surface only if the economic nouns remain precise. Appraisal, estimate, asking price, standing offer, proxy maximum, leading eligible bid, close price, invoice amount, escrow-provider balance and settled consideration are different records produced by different authorities at different times.

### 42.1 Economic value and listing semantics

| Object | Who/what produces it | What it does not prove |
| --- | --- | --- |
| Appraisal | identified appraiser/model using a dated comparable set and method | offer, liquidity, title, future price or guaranteed sale |
| AskingPrice | authorized seller/listing manager | accepted value or enforceable bid |
| Offer | authenticated buyer under exact terms and expiry | funds, eligibility, title transfer or auction rank |
| BidAdmission | serialized auction service after eligibility/terms checks | settlement success or legal title |
| CloseReceipt | locked auction algorithm at the close fence | payment, inspection, custody, title or persona transfer |
| SettlementReceipt | completed saga plus provider assertions and journals | government registry truth beyond cited assertion |

```text
Listing is a versioned disclosure and authority package
Listing {
  listingId, subjectAssetId, configurationSnapshotId,
  sellerPrincipalId, sellerAuthorityRecordId, beneficiaryIds[],
  titleAndLienAssertionRefs[], custodyAssertionRefs[],
  conditionDossierDigest, disclosureArtifactDigest,
  includedItems[], excludedItems[], includedRights[], excludedRights[],
  personaDispositionPolicy, jurisdiction, currency, termsDigest,
  inspectionPolicy, settlementProfileId, status
}

Listing state:
  DRAFT -> AUTHORITY_PENDING -> DISCLOSURE_PENDING -> READY -> SCHEDULED
  -> OPEN -> PAUSED -> CLOSE_FENCED -> CLOSED -> SETTLING
  -> SETTLED | NO_SALE | FAILED | CANCELLED | DISPUTED
```

### 42.2 Auction rule set, bid admission, and anti-sniping

```text
Immutable bid and admission records
AuctionRuleSet {
  ruleSetId, auctionMode: DIRECT_ASCENDING|PROXY_MAXIMUM|SEALED,
  currency, openingAt, initialCloseAt, hardStopAt?,
  minimumIncrementFunction, tieRule, reservePolicy,
  bidderEligibilityPolicy, depositPolicy?, antiSnipingWindow?,
  extensionDuration?, maximumExtensions?, bidWithdrawalPolicy,
  pausePolicy, cancellationPolicy, visibilityPolicy,
  settlementProfileId, ruleSetDigest
}

BidIntent {
  bidId, auctionId, bidderPrincipalId, bidderAgentId?,
  amountMinor, maximumProxyMinor?, currency, termsDigest,
  confirmationArtifactId, depositHoldId?, clientCreatedAt,
  submittedAt, idempotencyKey, bidDigest
}

BidAdmissionReceipt {
  bidId, auctionId, auctionStreamSequence, trustedReceivedAt,
  eligibilityDecisionId, fundsDecisionId?, admittedAmountMinor,
  encryptedProxyMaximumRef?, ruleSetDigest, bidDigest,
  status: ADMITTED|REJECTED, reasonCode?
}
```

```text
Deterministic extension rule
if trustedReceivedAt < currentCloseAt
   and trustedReceivedAt >= currentCloseAt - extensionWindow
   and bidAdmission == ADMITTED:
  newCloseAt = min(hardStopAt,
                   max(currentCloseAt, trustedReceivedAt + extensionDuration))
  append AuctionExtended(triggeringBidId, previousCloseAt, newCloseAt,
                         ruleSetDigest, auctionStreamSequence)

The close boundary is strict: trustedReceivedAt < currentCloseAt.
Client clocks, feed order, UI refresh and notification delivery do not rank bids.
```

- The reserve is signed/encrypted or independently witnessed before opening. The seller cannot select or change it after observing admitted bids.

- Public projections pseudonymize bidders and never reveal proxy maxima, excluded-account relationships, deposits, funding checks or exact device/network features.

- A bid is immutable. Withdrawal, seller/related-party exclusion, deposit failure and administrative invalidation append separate records with evidence and appeal semantics.

- Proxy bidding stores the authenticated maximum encrypted from public/read models. The close algorithm computes the visible price from eligible maxima, increment function and locked tie rule.

### 42.3 Linearizable close and winner selection

```text
Per-auction serialized close transaction
closeAuction(auctionId, expectedStreamHead):
  begin SERIALIZABLE transaction
  auction = lock auction stream
  require auction.streamHead == expectedStreamHead
  require auction.state in {OPEN, PAUSED_AS_CLOSEABLE}
  require trustedNow >= auction.currentCloseAt

  append CloseFence(fenceSequence=nextSequence,
                    trustedCloseTime, ruleSetDigest)
  bids = ADMITTED bids with admissionSequence < fenceSequence
  eligible = reevaluate locked close-eligibility policy over bids
  result = lockedAlgorithm(eligible, reserveCommitment,
                           incrementFunction, tieRule)
  append AuctionCloseReceipt(
    closeFenceSequence, exactEligibleBidIds, excludedBidFindings,
    winnerBidId?, closingPriceMinor?, reserveDisposition, noSaleReason?,
    algorithmDigest, resultDigest)
  transition to CLOSED or NO_SALE
  commit

Only AuctionCloseReceipt selects the winner. A later higher offer, payment order,
feed order, seller preference or appraisal cannot replace it.
```

### 42.4 Settlement saga and independent legal/physical milestones

```text
Payment, escrow, inspection, custody, title, persona and rights do not collapse
SettlementSaga {
  settlementId, auctionCloseReceiptId, buyerPrincipalId, sellerPrincipalId,
  beneficiaryIds[], settlementProfileId, purchaseAgreementDigest,
  paymentIntentId?, escrowProviderId?, escrowOperationId?,
  titleAndLienCheckIds[], inspectionDecisionId?, taxAndFeeQuoteId?,
  documentExecutionIds[], custodyHandoffId?, titleTransferAssertionId?,
  personaDispositionId?, rightsDispositionIds[], milestoneStates[],
  compensationIds[], disputeId?, finalReceiptId?
}

Milestones:
  PREFLIGHT -> BUYER_IDENTITY_VERIFIED -> SELLER_AUTHORITY_VERIFIED
  -> TITLE_AND_LIEN_REVIEWED -> FUNDS_AUTHORIZED -> FUNDS_IN_ESCROW
  -> INSPECTION_PASSED|WAIVED|FAILED -> DOCUMENTS_EXECUTED
  -> CUSTODY_HANDOFF_CONFIRMED -> TITLE_TRANSFER_EXTERNALLY_ASSERTED
  -> ACCEPTANCE_CONFIRMED -> FUNDS_RELEASED -> COMPLETE

Incomplete milestone -> SUSPENDED -> COMPENSATING
  -> REFUNDED | PARTIALLY_COMPENSATED | DISPUTED | OPERATOR_REQUIRED
```

```text
External legal authority remains external
The platform does not claim to provide regulated escrow unless the responsible entity is authorized to do so. Payment success does not transfer title. Custody does not transfer persona, voice, media, telemetry or profile rights. Registry output is an attributed assertion, not a fact manufactured by the platform.
```

### 42.5 Double-entry subledger and exact money

```text
Canonical accounting invariants
LedgerAccount {
  accountId, legalAccountHolderId,
  accountType: ASSET|LIABILITY|EQUITY|REVENUE|EXPENSE|MEMORANDUM,
  currency, providerRef?, restrictedPurpose?, status
}

JournalBatch {
  journalBatchId, economicEventId, journalPolicyDigest,
  status: DRAFT|VALIDATED|POSTED|REVERSED,
  bookedAt, effectiveAt, currencyGroups[], lines[], sourceReceiptIds[],
  reversalOf?, periodId, postingDigest
}

JournalLine {
  lineId, accountId, currency, debitMinor, creditMinor,
  vehicleId?, personaId?, missionId?, beneficiaryId?,
  providerRef?, taxCodeRef?, revenueShareRef?
}

For each currency group: sum(debitMinor) == sum(creditMinor).
Each line has exactly one positive side. Posted batches are immutable.
Corrections append a full/partial reversal and a replacement. One economic event
has at most one active posted batch under one journal policy.
```

| Example event | Debit | Credit |
| --- | --- | --- |
| buyer funds EUR 100,000 | Cash—regulated provider 100,000 | Liability—buyer funds held 100,000 |
| allocate settlement | Liability—buyer funds held 100,000 | Payable—seller 95,000; platform revenue 4,000; tax payable 1,000 |
| seller payout | Payable—seller 95,000 | Cash—regulated provider 95,000 |
| platform transfer | Cash—operating 4,000 | Cash—regulated provider 4,000 |
| tax remittance | Tax payable 1,000 | Cash—regulated provider 1,000 |

The example demonstrates mechanics, not prescribed legal or tax treatment. Currencies balance independently. FX uses explicit balanced currency groups through an FX-clearing account with rate source, quotation direction, timestamp, spread/fee and realized/unrealized treatment. Binary floating money is forbidden.

### 42.6 Economic mandates and atomic reservations

```text
Concurrent actions cannot overspend a mandate
EconomicMandate {
  mandateId, principalId, beneficiaryId, agentInstanceId,
  allowedActionKinds[], allowedCounterparties[], allowedMerchantCategories[],
  prohibitedCounterparties[], perActionLimitsByCurrency{},
  periodLimitsByCurrency{}, rollingWindowPolicy, confirmationThresholds{},
  maximumOpenReservations, validInterval, mandateEpoch
}

BudgetReservation {
  reservationId, mandateId, actionId, currency, amountMinor,
  status: HELD|CONSUMED|RELEASED|EXPIRED|DISPUTED,
  heldAt, expiresAt, consumedByEconomicEventId?
}

lock mandate counter
if postedUsage + activeReservations + requestedAmount > periodLimit: reject
else append HELD reservation and increment active reservation total atomically
```

### 42.7 Unknown-effect reconciliation and exactly-once economics

```text
Provider uncertainty remains explicit
reconcile(operationId):
  lock operation stream
  if state != UNKNOWN_EFFECT: return current state
  evidence = query provider by immutable providerOperationId or idempotencyKey
  verify provider identity, signature, schema and correlation

  if provider proves success:
    append EffectConfirmed
    create entitlement/payment/market records exactly once
    post journal exactly once; consume reservation; settle action
  elif provider proves no effect:
    append ProvenNotEffected; release reservation
    retry only if proposal, confirmation, grants and connector policy remain valid
  elif evidence conflicts or reconciliation deadline passes:
    append OperatorRequired; preserve reservation or book explicit exposure
    prohibit automatic retry

Webhook and poll races converge on one provider operation, economic event and
active journal batch. Timeout never means failure; ambiguous not-found never
authorizes blind retry for a non-idempotent provider.
```

### 42.8 Asset transfer and persona succession saga

```text
Transfer is a coordinated revocation and succession transaction
TransferPlan {
  transferPlanId, assetId, transferorPrincipalIds[], transfereePrincipalIds[],
  titleDisposition, custodyDisposition, profileAdministrationDisposition,
  personaDisposition: TRANSFER|RETAIN|LICENSE|FORK|RETIRE,
  followerGraphDisposition, historicalContentDisposition,
  mediaRightsDisposition, telemetryAndPrivateDataDisposition,
  outstandingListingIds[], outstandingAuctionIds[], outstandingActionIds[],
  scheduledPublicationIds[], economicMandateIds[], providerCredentialRefs[],
  legalHoldRefs[], effectiveAt, approvalRequirements[], state
}

DRAFT -> COUNTERPARTIES_VERIFIED -> RIGHTS_RESOLVED
  -> OUTSTANDING_EFFECTS_RESOLVED -> QUIESCING -> HANDOVER_COMMITTED
  -> EPOCHS_ADVANCED -> CREDENTIALS_ROTATED
  -> PUBLIC_SUCCESSION_DISCLOSED -> COMPLETE

Any pre-commit state -> ABORTED
Any unresolved post-effect state -> OPERATOR_REQUIRED
```

- EPOCHS_ADVANCED invalidates sale, publication, spending and profile grants; active sessions/tokens; provider credentials/webhooks; cached decisions; scheduled content; campaigns; unconsumed confirmations; recovery delegates and prior-steward invitations.

- Historical content retains original creator, source, rights and publication receipts. Followers receive an explicit transfer, licensed continuation, fork or retirement notice instead of a silent account takeover.

- Title, custody, profile administration, persona, follower graph, media, voice, telemetry, private data and economic rights each receive an explicit disposition; an omitted disposition blocks completion.

- Autonomous earning or service operation remains a mandate-bound workflow for named beneficiaries and accountable principals. The vehicle persona does not own money merely because it generates revenue.

# 43. Exact HTTP, event, query, federation, and SDK contracts

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.43 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:e7b392ee324333459791844e24462155fcd6e49db5eda9c462d5b479273df8c1

The API exposes three deliberately different resources: portable canonical records, store admission receipts, and policy-bound projections. A client must be able to tell which one it received from media type, path, schema lock, digest headers and response body. The v1.3 contract below supersedes the illustrative combined envelope in Section 14.2 and the v1.2 endpoint sketches wherever they conflict.

```text
Canonical bytes are not an audience view
GET /records/{recordId}/canonical returns the admitted portable bytes only to a principal authorized for that record class and representation. GET /vehicles/{assetId}/profile returns a rebuildable, redacted projection. Their ETags, digests, caching, deletion behavior and authorization are not interchangeable.
```

### 43.1 Endpoint matrix and consistency contract

| Method + path | Contract | Consistency / authority |
| --- | --- | --- |
| POST /v1/records:append | admit one RecordCore plus detached proofs | serializable per stream; expected sequence; idempotent scoped key |
| POST /v1/records:appendBatch | atomic one-stream batch; bounded count/bytes | all-or-none under one stream head |
| GET /v1/records/{id}/canonical | exact admitted representation and record digest | authoritative ledger; strong read after receipt checkpoint |
| GET /v1/records/{id}/receipt | admission placement, policy decision and chain position | authoritative ledger; tenant-bound |
| GET /v1/streams/{id}?afterSequence= | ordered canonical record/receipt pairs | monotonic stream sequence; signed continuation cursor |
| POST /v1/telemetry/sessions | declare capture locks and obtain upload capability | policy + quota checkpoint; no segment admitted yet |
| POST /v1/telemetry/segments:reserve | reserve bounded object upload and expected digests | short-lived; one manifest identity |
| POST /v1/telemetry/segments:commit | validate bytes + admit SegmentManifest | idempotent; duplicate/equivocation explicit |
| POST /v1/actions:propose | store inert typed proposal | no external effect |
| POST /v1/actions/{id}:confirm | consume exact challenge response | one-time; authenticated principal and terms digest |
| POST /v1/actions/{id}:dispatch | policy/mandate recheck + connector operation | compare-and-append; may return UNKNOWN_EFFECT |
| POST /v1/auctions/{id}/bids | admit confirmed bid intent | linearizable auction stream |
| POST /v1/auctions/{id}:close | create close fence and result | serializable single winner/no-sale receipt |
| GET /v1/vehicles/{id}/profile | audience and as-of bound projection | checkpoint-bounded, cacheable by projection ETag |
| POST /v1/queries | typed bounded query AST | snapshot checkpoint and policy digest returned |
| POST /v1/exports | asynchronous signed export manifest | checkpoint-pinned, policy filtered and auditable |

Strong consistency is required only where an invariant needs it: stream append, authority epoch, bid admission/close, budget reservation and journal posting. Search, feeds, analytics and public profiles are checkpointed projections and may lag; every response exposes that checkpoint and staleness. A client cannot request strong consistency by hiding a stale projection behind an uncached URL.

### 43.2 Append request headers and result

```text
Normative append exchange
POST /v1/records:append HTTP/1.1
Content-Type: application/vnd.rtracer.record+json;version=1.3
Accept: application/vnd.rtracer.ingest-receipt+json;version=1.3
Authorization: DPoP <short-lived-token>
DPoP: <proof bound to method, URL, token and key>
RTracer-Tenant: 5abfa9c8-4ec5-4de9-b786-3b3b1b1d8ed4
RTracer-Stream: 606f60af-fb14-42b4-8677-1ea9a35c2d5b
RTracer-Expected-Sequence: 184
RTracer-Writer-Epoch: 12
Idempotency-Key: 01JAZ...client-random...
Content-Digest: sha-256=:...:

Body = exact RecordCore bytes. Detached proofs are supplied as a bounded
multipart part or by digest-addressed ProofRecord references.

201 Created
Location: /v1/records/019b.../receipt
ETag: "receipt-sha256-..."
RTracer-Record-Digest: sha256:...
RTracer-Receipt-Digest: sha256:...
RTracer-Stream-Sequence: 185
RTracer-Logical-Shard: ledger-03
RTracer-Chain-Epoch: 1
RTracer-Commit-Sequence: 93828011

Retry of same scoped key + same requestDigest returns 200 and original receipt.
Same key + different requestDigest returns 409 RTR-IDEMPOTENCY-EQUIVOCATION.
```

- Request digest covers operation family, canonical body digest and semantic headers that affect the operation. Transport attempt count, TCP identity, trace ID and retry timing never enter the canonical event or record digest.

- A 202 response means admitted asynchronous work, never semantic record acceptance unless it contains a committed IngestReceipt. Upload reservation is not telemetry admission.

- If the connection fails after dispatch, the client queries the scoped idempotency key before retrying. It never changes the key for the same intended effect merely to escape an unknown result.

- Proof verification failure, schema failure, policy denial and storage failure use different stable codes. Safe responses never echo secrets, private identifiers, raw policy or existence of unauthorized resources.

### 43.3 Projection, ETag, cursor, and typed query semantics

```text
Reproducible view and confidential pagination contract
ProjectionDescriptor {
  projectionKind, projectionVersion, audienceClass, requestingPrincipalId?,
  purpose, validAt, knownAt, sourceCheckpointVector,
  policyBundleDigest, registryCheckpoint, codeDigest,
  locale, unitProfile, privacyTransformRefs[], inputRecordDigestSetDigest
}

projectionDigest = SHA256(domain("PROJECTION", version) ||
  canonicalize({descriptor, renderedSemanticObject}))

CursorBindingV1_4 {
  cursorProfile, queryDigest, requestingPrincipalId?, audienceClass,
  purpose, checkpointVector, projectionDescriptorDigest,
  codeDigest, registryCheckpoint, policyBundleDigest,
  sortPosition, expiresAt, keyEpoch
}

The client receives authenticated encryption of CursorBindingV1_4 or a random
server-side handle. Plaintext private sort tuples and tenant IDs are prohibited.
ProjectionDescriptor {
  projectionKind, projectionVersion, audienceClass, requestingPrincipalId?,
  purpose, validAt, knownAt, sourceCheckpointVector,
  policyBundleDigest, registryCheckpoint, codeDigest,
  locale, unitProfile, privacyTransformRefs[], inputRecordDigestSetDigest
}

projectionDigest = SHA256(
  domain("PROJECTION", version) ||
  canonicalize({descriptor, renderedSemanticObject})
)

Projection ETag = quoted projectionDigest.
Canonical-record ETag = quoted recordDigest.
They are never compared as equivalent validators.

CursorPayload {
  queryDigest, tenantId, principalOrAudienceBinding, purpose,
  checkpointVector, sortTuple, pageSize, policyDigest, expiresAt, nonce
}
cursor = base64url(payload) + "." + signature

A cursor is opaque, short-lived, tamper-evident and bound to the exact query,
policy and principal/audience. It is not a free-form database offset.
```

```text
Bounded typed query surface
Query {
  from: closed resource family,
  where: allOf|anyOf|not|eq|in|range|exists|relationshipPath,
  validAt, knownAt, projectionPurpose,
  select: allowlisted field paths,
  orderBy: stable indexed keys ending in opaque ID,
  page: {first: 1..500, after?: signedCursor},
  consistency: CHECKPOINTED|AT_LEAST_CHECKPOINT,
  minimumCheckpoint?: vector
}

Limits: depth 16; predicates 100; IN values 1,000; relationship depth 5;
wall time 5 s interactive/60 s export; scanned-row/byte budget per tenant.
No arbitrary expression, regex over unindexed private data, user SQL, mutation,
recursive graph query or model-selected query text is accepted.
```

### 43.4 Problem details and stable machine codes

```text
RFC 9457-compatible failure object
HTTP/1.1 409 Conflict
Content-Type: application/problem+json

{
  "type":"urn:rtracer:problem:stream-sequence-conflict",
  "title":"Stream sequence conflict",
  "status":409,
  "code":"RTR-LEDGER-EXPECTED-SEQUENCE",
  "stage":"admission.commit",
  "correlationId":"019b...",
  "retryable":true,
  "safeContext":{"expected":"184","current":"185"}
}

Fields are closed. detail is optional and localized; clients branch on code.
Validation findings carry JSON Pointer, constraint ID and safe rejected-value
class—not the private value. Retryable never overrides idempotency semantics.
```

| Code family | Representative codes | Default HTTP / disposition |
| --- | --- | --- |
| RTR-WIRE | NONCANONICAL, DIGEST-MISMATCH, SCHEMA-LOCK, UNKNOWN-MEMBER | 400/422; reject |
| RTR-AUTHN | TOKEN-BINDING, AUDIENCE, CREDENTIAL-REVOKED, STEP-UP | 401; deny/challenge |
| RTR-AUTHZ | NO-GRANT, EXPLICIT-DENY, STALE-EPOCH, UNSATISFIED-DUTY | 403; deny |
| RTR-LEDGER | EXPECTED-SEQUENCE, WRITER-EPOCH, IDEMPOTENCY-EQUIVOCATION | 409; retry/query/quarantine |
| RTR-TELEM | SEGMENT-EQUIVOCATION, CLOCK, DECOMPRESSION-LIMIT, DESCRIPTOR | 409/422; quarantine/reject |
| RTR-COMP | PORT-INCOMPATIBLE, SOLVER-NONCONVERGENT, EFFECTIVITY-UNKNOWN | 422; false/unknown/error |
| RTR-CONTROL | AUTHORITY-EPOCH, FRAME, ENVELOPE, HANDOVER-TIMEOUT | 409/422; reject/fallback |
| RTR-MARKET | AUCTION-CLOSED, TERMS, BID-INELIGIBLE, CLOSE-CONFLICT | 409/422; reject/reload |
| RTR-MONEY | MANDATE, JOURNAL-UNBALANCED, UNKNOWN-EFFECT, RECONCILIATION | 409/422/202; hold/operator |
| RTR-PRIVACY | PURPOSE, NONINTERFERENCE, RETENTION-CONFLICT, RIGHTS | 403/409; deny/freeze |

### 43.5 CloudEvents transport profile and topic catalog

```text
At-least-once event envelope
CloudEvent attributes:
  specversion = "1.0"
  id          = eventId (UUIDv7; stable across delivery retries)
  source      = urn:rtracer:service:<serviceId>
  type        = io.rtracer.<domain>.<event>.v1
  subject     = opaque canonical subject route; never VIN/MAC/plate/person
  time        = transaction/recorded time, not necessarily validTime
  datacontenttype = application/vnd.rtracer.event+json;version=1.3
  dataschema  = immutable schema URI containing or resolving to digest
  tenantid, shardid, shardposition, streamid, streamsequence,
  recordid?, recorddigest?, receiptdigest?, correlationid, causationid

data = canonical EventData referencing records/receipts by ID and digest.
transportAttempt, broker partition/offset, delivery time, retry count,
consumer lag and trace propagation are delivery metadata outside EventData.
CloudEvents serialization is a transport envelope, not RecordCore identity.
```

| Topic family | Partition key | Consumer obligation |
| --- | --- | --- |
| record.admitted.v1 | tenantId + logicalShardId + chainEpoch | one event per receipt; preserve commitSequence order; atomically dedupe, mutate projection, and advance checkpoint |
| record.invalidated.v1 | tenantId + affected streamId | invalidate/rebuild descendants by dependency graph |
| telemetry.segment-admitted.v1 | tenantId + captureSessionId | honor manifest locks and gap/correction events |
| configuration.compiled.v1 | tenantId + assetId | discard older config/context result; retain proof receipt |
| action.state-changed.v1 | tenantId + actionId | enforce legal sequence; never infer effect from delivery |
| auction.state-changed.v1 | tenantId + auctionId | preserve stream order; result only from close receipt |
| journal.posted.v1 | tenantId + economicEventId | exactly-once projection by batch ID; never repost |
| publication.changed.v1 | tenantId + publicationId | apply correction/withdrawal lineage and audience policy |

The outbox is authoritative for event production. Broker delivery is at least once. Consumers store event ID plus source checkpoint in the same transaction as their materialized state. Poison messages enter a bounded quarantine lane with alerting; skipping without a recorded gap decision is forbidden.

### 43.6 SDK behavioral contract

| SDK layer | Required behavior | Forbidden convenience |
| --- | --- | --- |
| wire | strict builders; exact integers/decimals; canonicalize; digest; local schema/vocabulary locks | map unknown enum to first/default; silently normalize signed data |
| auth | DPoP/mTLS support, audience check, key protection, step-up challenge | long-lived bearer token in app storage/logs |
| append | stable idempotency key, expected sequence, receipt verification, unknown-result query | automatic new key after timeout |
| query | typed AST, signed cursor, checkpoint/staleness exposure, redaction marker types | raw query string or hiding projection checkpoint |
| telemetry | descriptor/session lock, bounded chunking, exact bit patterns, resumable digest-verified upload | unit/frame conversion in raw capture batch |
| actions | proposal/confirmation/dispatch types; legal state parser; reconciliation polling | report timeout as failure or payment success as title |
| events | dedupe, monotonic stream handling, checkpoint atomicity and quarantine | assume global order or exactly-once broker |
| offline edge | local signed journal, monotonic local sequence, pack lock, conflict-preserving sync | last-write-wins over lifecycle/evidence/authority |

Generated SDKs are subordinate to semantic fixtures. Each supported language must reproduce canonical golden bytes/digests, exact UUID grammar, unit/dimension vectors, proof verification, HTTP retries, cursor rejection, event deduplication and error-code exhaustiveness. A generator release is not conforming until its language-specific corpus passes byte-for-byte.

### 43.7 Offline synchronization, import/export, and federation

```text
Disconnected capture and portable dossier contract
EdgeJournalEntry {
  edgeDeviceId, bootId, localSequence, recordId, canonicalBytes,
  recordDigest, proofRefs[], packLock, capturedAtDevice,
  priorLocalDigest, localDigest, syncState
}

Sync:
  1 authenticate device/workload and authorize exact journal scope
  2 compare server acknowledgement vector and local chain
  3 upload missing bytes/proofs with stable per-record idempotency keys
  4 admit independently; preserve conflicts/equivocation and server receipts
  5 append SyncReceipt mapping local sequence to admission disposition
  6 never rewrite edge history; append corrections/invalidation

ExportManifest pins tenant, subject selectors, purpose, policy decision,
source checkpoint, schema/vocabulary/pack locks, record and artifact digests,
encryption recipients, redactions, retention/recipient duties and signature.
Import verifies bytes first, then maps external IDs as assertions; it never
assumes imported tenant, ownership, grants or registry status are local truth.
```

- Public ActivityPub objects remain projections. Remote Actor/Note/Follow/Like IDs never become vehicle, principal, grant, bid, appraisal or lifecycle evidence IDs.

- Federated inbox content is quarantined untrusted data. It cannot invoke tools, promote memory, reveal private dossiers or enter the physical-control plane.

- Withdrawal/correction propagates best-effort to federated copies with durable receipts, while the system reports that remote deletion cannot be guaranteed.

- Government, insurer, workshop and event adapters preserve issuer, native identifier/value, fetch/import time, effective time, source artifact and transformation receipt. They do not flatten external claims into owner-authored facts.

# 44. Reference implementation, operations, capacity, and release engineering

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.44 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:96209b72832cf6f85e35d23badfde60859fb381f2e6f812576819e17d5572623

A universal semantic model does not require one monolith or one vendor stack. The reference profile below fixes trust, consistency, replay and operability boundaries so implementations can vary without weakening meaning. Deployments may combine services initially, but they must preserve independent credentials, data access and failure semantics at every plane boundary.

### 44.1 Logical service topology

| Service boundary | Authoritative responsibility | Primary state / dependency |
| --- | --- | --- |
| registry | schemas, vocabularies, packs, migrations and trust metadata | content-addressed registry + signed metadata |
| identity | principals, credentials, sessions, recovery and epochs | credential store + HSM/KMS + WebAuthn/SPIFFE |
| admission ledger | canonicalization, proofs, policy gate, stream append and receipts | PostgreSQL authoritative ledger |
| artifact custody | bounded upload, malware/parser isolation, byte integrity and encryption | S3-compatible immutable/versioned object store |
| telemetry | capture sessions, segment validation, clock/channel quality and manifests | ledger + object store + Parquet/Iceberg projection |
| configuration compiler | graph realization, capability proof, envelope and model registry | ledger snapshot + deterministic worker sandbox |
| projection/query | policy-bound profiles, feeds, search, graph and exports | rebuildable PostgreSQL/OpenSearch/Iceberg stores |
| agent/content | context manifests, grounded drafts, persona and publication lifecycle | filtered projections; no credentials/effect access |
| policy | ABAC/ReBAC, rights/consent, risk, duties and decision receipts | versioned Rego-equivalent bundle + relationship checkpoints |
| action broker | typed connectors, reservations, dispatch, webhook and reconciliation | action streams + secret vault + provider adapters |
| market | listings, bid streams, close, settlement milestones | serializable streams + provider assertions |
| accounting | mandates, reservations, journals, reconciliation and reports | append-only balanced subledger |
| event plane | outbox publication, durable topics and consumer checkpoints | Kafka/Redpanda-compatible log; at-least-once |
| safety control | certified/local control authority and telemetry bridge | separate network, credentials, schemas and release process |

```text
Reference stack is replaceable; invariants are not
PostgreSQL, an S3-compatible object store, Parquet/Iceberg, Kafka-compatible events, OpenSearch, an OPA/Rego-equivalent policy engine, SPIFFE workload identity and HSM/KMS-backed keys are a practical reference composition. Redis may cache disposable results only; it is never authoritative for grants, budgets, auction rank, stream heads or journal balances.
```

### 44.2 Data placement, consistency, and tenancy

| Data class | Authoritative location | Partition / consistency rule |
| --- | --- | --- |
| RecordCore + receipts | PostgreSQL ledger | tenant + semantic stream; serializable append; synchronous replica policy by tier |
| large artifacts | versioned immutable object storage | tenant key prefix is not authorization; manifest digest + envelope encryption |
| telemetry analytics | Parquet tables under Iceberg snapshots | partition by tenant/date/domain bucket; source manifest/ledger checkpoint retained |
| search/feed | OpenSearch or relational materialization | eventual; document contains source checkpoint/policy class; fully rebuildable |
| graph/relationships | ledger + indexed projection | valid/known-time aware; authority queries bind graph checkpoint |
| secrets/keys | dedicated vault/HSM/KMS | never in records, events, images, prompts or analytic lake |
| operational observability | separate telemetry backend | tenant-minimized; no raw lifecycle payload by default |

- Tenant isolation combines service identity, tenant-bound authorization, forced row-level security, per-tenant encryption context, object-policy checks, topic ACLs, query budgets and non-interference tests. Any one layer failing must not disclose data.

- Canonical records may be physically partitioned, but a move between partitions or regions changes no RecordCore bytes. New custody/admission receipts describe replication/export/import where required.

- Cross-region active-active writes are permitted only with a single fenced writer per semantic stream or a formally defined conflict-preserving stream protocol. Last-write-wins is forbidden for evidence, authority, auctions, budgets and journals.

- Projections advertise maximum source checkpoint and build digest. A partially rebuilt view is either held unavailable or labeled with a bounded checkpoint; mixed silent generations are forbidden.

### 44.3 Capacity model and backpressure

```text
Sizing equations and hard admission budgets
ledger_write_bytes_per_second =
  admitted_records_per_second *
  (canonical_bytes + indexes + receipt + outbox + WAL_replication_factor)

telemetry_ingress_bytes_per_second =
  active_assets * channels_per_asset * samples_per_second *
  encoded_bytes_per_sample / compression_ratio

object_capacity = retained_encoded_bytes * replica_factor *
                  versioning_overhead * safety_margin

projection_lag_seconds ~= queued_events / sustained_consumer_rate

Reference admission limits per tenant/profile:
  RecordCore: 8 MiB; append batch: <=100 records and <=32 MiB
  telemetry segment: <=256 MiB encoded, <=1 GiB decoded, <=100:1 expansion
  query: <=500 rows/page, <=5 s interactive, explicit scan budget
  export: asynchronous, checkpoint-pinned, quota and expiry controlled

Every queue has finite depth, age alarm and deterministic shed policy.
Never acknowledge semantic acceptance merely because bytes entered a queue.
```

| Pressure signal | Shed/degrade behavior | Never sacrifice |
| --- | --- | --- |
| ledger lock/serialization contention | 429/503 before work; retry-after + same idempotency key; split hot streams by semantics only | stream order, receipt durability, policy gate |
| artifact/object pressure | stop reservations, shorten upload expiry, preserve committed manifests | digest verification and orphan reconciliation |
| event consumer lag | slow noncritical projections; prioritize invalidation/action/market/accounting | outbox durability and ordered stream handling |
| query/search overload | reduce page/export concurrency; serve checkpointed cache with visible staleness | authorization and non-interference |
| model/agent overload | queue/disable generation and scheduled content | grounding, rights, approval and connector isolation |
| provider degradation | open circuit; enter UNKNOWN_EFFECT only after possible dispatch | idempotency, reservation and reconciliation evidence |

### 44.4 Service-level objectives and error budgets

| Capability | Reference SLI / objective | Correctness guard |
| --- | --- | --- |
| record append | 99.95% successful authorized appends monthly; p95 <300 ms, p99 <1 s excluding large proofs | receipt durable before success; no duplicate semantic append |
| canonical read | 99.99%; p99 <250 ms in home region | digest revalidation sampling; read at/after requested checkpoint |
| public profile | 99.9%; p95 <500 ms; 99% projection lag <60 s | staleness/checkpoint exposed; privacy never relaxed |
| telemetry commit | 99.9%; 99% accepted segment assessment <2 min after upload | no derivation before verified manifest commit |
| bid admission/close | 99.99% during open auctions; p99 admit <500 ms; close result <5 s | linearizable ordering and one close receipt |
| R3/R4 action | 99.9% decision plane; provider-dependent completion tracked separately | no positive decision on policy outage; no blind retry |
| journal posting | 99.99%; p99 <1 s after confirmed economic event | balanced exact minor units; at most one active posting |
| revocation propagation | 99.99% critical cache/token invalidation <30 s | dispatch rechecks current epoch even before convergence |

Correctness, privacy, safety and accounting invariants are not error-budget spend. An SLO may permit delayed availability, never unauthorized disclosure, fabricated acceptance, double charge, unbalanced journal, winner change or social-plane actuation. Exhausted availability budget freezes risky releases and funds reliability work.

### 44.5 Backup, disaster recovery, and deterministic replay

```text
Recovery is proved by replay, not asserted by backup status
Reference recovery tiers:
  Tier A — identity, grants, auctions, actions, accounting, stream heads
           RPO <= 1 minute; RTO <= 1 hour; multi-zone synchronous durability
  Tier B — canonical lifecycle ledger and manifests
           RPO <= 5 minutes; RTO <= 4 hours
  Tier C — rebuildable search/feed/analytics
           RPO = source checkpoint; RTO <= 24 hours

Restore procedure:
  1 isolate destination and verify backup/catalog signatures
  2 restore database and immutable artifacts to a named recovery point
  3 validate stream heads, unique constraints, receipt chains and checkpoints
  4 verify every admitted artifact manifest resolves and byte digests match
  5 restore each projection state snapshot with its exact checkpoint, or start empty at genesis and replay the complete required prefix
  6 compare deterministic projection digests and conformance probes
  7 reconcile provider operations and preserve UNKNOWN_EFFECT exposures
  8 advance deployment/recovery epoch; rotate credentials as required
  9 issue signed RecoveryAttestation before serving writes/critical reads

Backups are encrypted, access-separated, restore-tested and retention-governed.
Snapshot existence without routine restore verification is not recovery evidence.
```

### 44.6 Observability and privacy-safe operations

| Signal | Required dimensions | Sensitive-data rule |
| --- | --- | --- |
| admission metrics | stage, schema family, result code, size bucket, latency, shard | no record body, VIN, plate, MAC or free-form error |
| ledger metrics | transaction retries, lock wait, stream contention, WAL/replica lag, partition | opaque stream hash with rotating operational salt |
| event metrics | topic, consumer, checkpoint lag, redelivery, quarantine age | no canonical event payload in metric labels |
| policy metrics | decision effect, policy version, risk tier, duty/challenge class | no grant graph or protected attribute values |
| agent metrics | model/deployment digest, context size, claim outcomes, injection alerts | no prompt/evidence text by default; sampled access requires separate grant |
| market metrics | auction state, admission/close latency, reconciliation age | no bid amount or bidder ID in generic telemetry |
| security audit | principal/workload, action, resource IDs, outcome, epoch, checkpoint | dedicated access/retention; immutable receipt refs |

Trace context is operational correlation only; it never becomes domain identity, provenance or authorization. Logs are structured, field-allowlisted, size-bounded and sanitized before export. Sampling may reduce success traces, but never drops security decisions, R3/R4 state transitions, bid admission/close, journal posting, credential changes or disclosure receipts.

### 44.7 Supply chain, migration, and release gates

```text
Evidence-bearing software and semantic release
Release candidate inputs:
  source commit + hermetic build recipe + dependency lock + compiler/runtime IDs
  signed SBOM + provenance attestation + vulnerability/license results
  schema/vocabulary/pack/migration digests + policy bundle + connector manifests
  database migration plan + rollback/forward-fix classification
  deterministic golden vectors + stateful conformance fixtures + load results

Promotion gates:
  G0 static validation and secret scan
  G1 unit/property/fuzz tests; canonical byte equality across languages
  G2 ephemeral full stack; migrations up/down where reversible
  G3 security, tenant non-interference, abuse, parser and policy denial tests
  G4 ledger replay and empty-projection rebuild digest comparison
  G5 bid/budget/journal concurrency and provider unknown-effect chaos tests
  G6 canary with read shadowing and projection diff; no critical invariant drift
  G7 signed ReleaseEvidence and staged rollout with automatic stop conditions

Schema semantics, canonicalization, authorization and journal meaning never use
an untracked feature flag. Emergency disable is fail-closed and auditable.
```

- Every container/plugin/pack/migration/connector artifact is digest-pinned and verified before activation. Mutable latest tags are forbidden in production manifests.

- Database changes follow expand → dual-read/shadow-compare → backfill with receipts → cutover → contract after retention. A destructive contract step requires verified export/rollback evidence and policy approval.

- A registry or model revocation prevents new use immediately but retains the artifact needed to verify historical records. Replacement never rewrites prior locks.

- Chaos scenarios include replica loss, serialization storms, object corruption, broker duplication/reordering, stale policy cache, clock discontinuity, partial provider success, webhook/poll race, KMS outage and regional failover.

### 44.8 Staged build plan and measurable exit criteria

| Stage | Build scope | Exit evidence |
| --- | --- | --- |
| 0 semantic kernel | RecordCore, proofs, receipts, registry locks, canonical vectors, tenant policy | all wire fixtures; two-language byte equality; replayed receipt chain |
| 1 KUN dossier | identity assertions, configuration, maintenance/care/media, telemetry session and public profile | private/public non-interference; full profile rebuild from empty projection |
| 2 universal machine | ports/graphs, capability compiler, domain packs, RC/blimp/fan-bike/cross-domain traces | proof DAGs and fixtures across at least six differentiating domains |
| 3 vehicle persona | persona/canon, grounded content, voice/media provenance, federation adapter | unsupported claims blocked; rights withdrawal freezes content |
| 4 governed actions | identity/grants, confirmation, mandate, typed connector, reconciliation | R0–R4 cases; no agent secrets/generic tools; unknown-effect chaos passes |
| 5 market | listing, auction, close, settlement provider, accounting and transfer | concurrency proof, balanced journals, dispute bundle and succession revocation |
| 6 ecosystem | SDKs, external registries, workshops/events, recruitment domain, partner/franchise surfaces | adapter certification, privacy reviews, language SDK corpus and partner replay |
| 7 autonomous economy | continuous missions, dynamic service/rental/robotaxi/eVTOL integrations under mandates | jurisdiction/safety approvals, local safety separation and bounded beneficiary economics |

KUN ‘Prague Workhorse’ should remain the reference integration asset throughout: each stage adds real records, fixtures and a rebuilt product view to the same permanent identity. The demonstration succeeds when the story becomes richer without weakening evidence, privacy, authority, safety or replay.

# Appendix A. Official design signals and reference register

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.appendix.a · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:4ccf25b90da1528391cb9dc239483b7cff3fb8e7275a36287bb85b18e8b7f369

These sources inform the architecture and mappings. They do not grant RTracer access, redistribution rights, certification, legal authority or conformance. Controlled standards are referenced at the level of their official public descriptions; RTracer must license any normative text it needs to implement directly.

### A1 — SAE J3016

Six levels for on-road driving-automation systems; the scope reinforces function/task and operational-context modeling rather than a universal machine ladder.

https://saemobilus.sae.org/standards/j3016_202104-taxonomy-definitions-terms-related-driving-automation-systems-road-motor-vehicles

### A2 — NIST ALFUS

Autonomy framework considering human independence, mission complexity and environmental complexity for unmanned systems.

https://www.nist.gov/publications/autonomy-levels-unmanned-systems-alfus-framework-volume-ii-framework-models-version-10

### A3 — IMO autonomous shipping

Function- and mode-oriented treatment of maritime autonomous operation and remote operation.

https://www.imo.org/en/mediacentre/hottopics/pages/autonomous-shipping.aspx

### A4 — IMO ship-type definitions

Official maritime material notes that ship-type definitions are not universally applicable across instruments.

https://www.imo.org/en/ourwork/safety/pages/regulationsdefault.aspx

### A5 — EASA drone operations

Open, Specific and Certified are operation-risk categories, demonstrating why classification can attach to an operation rather than only the aircraft.

https://www.easa.europa.eu/en/domains/drones-air-mobility/operating-drone

### A6 — EU road M/N/O categories

Passenger, goods and trailer categories plus vehicle type/variant/version concepts.

https://eur-lex.europa.eu/eli/reg/2018/858/oj/eng

### A7 — EU L-category vehicles

Powered cycles, mopeds, motorcycles, sidecars and quadricycles under a road-specific regulatory scheme.

https://eur-lex.europa.eu/legal-content/en/ALL/?uri=CELEX%3A32013R0168

### A8 — EU agricultural T/C/R/S

Wheeled/tracked tractors, trailers and interchangeable towed equipment.

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32013R0167

### A9 — FAA aircraft glossary

Aircraft categories include airplane, glider, lighter-than-air, powered-lift and rotorcraft, supporting facet-separated classification.

https://www.faa.gov/air_traffic/publications/atpubs/pcg_html/glossary-a.html

### A10 — European Register of Authorised Types of Vehicles

Rail type, variant/version and authorization are separate from the individual vehicle record.

https://www.era.europa.eu/domains/registers/eratv_en

### A11 — European Vehicle Register

Individual rail vehicle registration and keeper data illustrate separate identity and registry assertions.

https://www.era.europa.eu/registers/evr_en

### A12 — NASA Small Spacecraft State of the Art

Cross-system treatment of propulsion, power, GNC, structures, thermal, avionics, communications, deployment, operations, tracking and deorbit.

https://www.nasa.gov/smallsat-institute/sst-soa/

### A13 — NASA in-space propulsion

Chemical, electric and propellantless propulsion families provide official cross-domain vocabulary signals.

https://www.nasa.gov/smallsat-institute/sst-soa/in-space_propulsion/

### A14 — IEC 81346-1

General principles for structuring systems and unambiguous reference designations across technologies and multiple aspects.

https://webstore.iec.ch/en/publication/64021

### A15 — ISO 10007

Configuration management guidance from concept through disposal.

https://www.iso.org/standard/70400.html

### A16 — ISO 14224

Equipment taxonomy, failure cause/consequence and maintenance action/resources/downtime are strong generic lifecycle patterns.

https://www.iso.org/standard/64076.html

### A17 — ISO 3833

Road-vehicle type terms; useful as a road pack vocabulary, not a universal root ontology.

https://www.iso.org/standard/9389.html

### A18 — ISO 19649

Vocabulary for mobile robots moving on solid surfaces.

https://www.iso.org/standard/65658.html

### A19 — ISO 10303-239 PLCS

Product-life-cycle support, parts, versions, structures, interfaces, configuration and maintenance history.

https://www.iso.org/standard/78832.html

### A20 — VMRS

Maintenance system-to-part hierarchy and extensible component/work/failure code concepts.

https://tmc.trucking.org/VMRS-Overview

### A21 — ATA iSpec

Aircraft-system numbering and technical-information standards as an aviation interoperability signal.

https://ataebiz.org/standards/

### A22 — W3C PROV-O

Interchangeable provenance entities, activities and agents for heterogeneous systems.

https://www.w3.org/TR/prov-o/

### A23 — W3C SHACL

A standard language for expressing and validating constraints over RDF graphs.

https://www.w3.org/TR/shacl/

### A24 — W3C JSON-LD 1.1

JSON-based linked-data representation useful for semantic export without requiring the application store to be RDF-native.

https://www.w3.org/TR/json-ld11/

### A25 — W3C SSN/SOSA

Separates sensor, observation, procedure, actuator and actuation, including phenomenon and result time.

https://www.w3.org/TR/vocab-ssn/

### A26 — IMO ship identification

A permanent ship identifier designed to persist across changes such as name, flag and ownership.

https://www.imo.org/en/ourwork/iiis/pages/imo-identification-number-schemes.aspx

### A27 — UNOOSA space treaties

Space registration materials encompass space objects, launch vehicles and component parts.

https://www.unoosa.org/oosa/SpaceLaw/treaties.html

### A28 — JSON Schema 2020-12

Machine-readable JSON structure and validation vocabulary; useful for compact wire contracts when extension and remote-reference policy are controlled.

https://json-schema.org/draft/2020-12

### A29 — W3C SKOS

Concept schemes, preferred/alternative labels, hierarchy and mapping relationships for governed vocabularies.

https://www.w3.org/TR/skos-reference/

### A30 — OGC SensorThings API

Open geospatial IoT model with separate sensing and tasking functions; useful as an observation/actuation interoperability adapter.

https://www.ogc.org/standards/sensorthings/

### A31 — COVESA Vehicle Signal Specification

A syntax and catalog for road-vehicle signals with overlays; useful as a signal adapter rather than a universal cross-domain tree.

https://covesa.github.io/vehicle_signal_specification/index.html

### A32 — ASAM OpenODD

A machine-readable model and exchange formats for operational design domains, operational domains and current domains in automated driving.

https://www.asam.net/standards/detail/openodd/

### A33 — ASAM MDF and ODS

Measurement-file and test-data management standards that can anchor RTracer test/telemetry adapters without defining the lifecycle kernel.

https://www.asam.net/standards/detail/mdf/

### A34 — GS1 EPCIS 2.0

Cross-enterprise visibility events for objects, aggregations, transformations and business context; valuable for part, lot and custody mappings.

https://ref.gs1.org/standards/epcis/2.0.0/

### A35 — W3C ODRL

An information model for permissions, prohibitions and duties; useful for rights exchange while internal action grants remain stricter.

https://www.w3.org/TR/odrl-model/

### A36 — W3C Verifiable Credentials 2.0

Issuer-holder-verifier claims with integrity and privacy semantics; a signature authenticates provenance, not universal truth.

https://www.w3.org/TR/vc-data-model-2.0/

### A37 — C2PA specifications

Content provenance, binding and edit-lineage signals for media and synthetic disclosure.

https://spec.c2pa.org/specifications/

### A38 — JCGM 100 measurement uncertainty

General guidance for evaluating and expressing measurement uncertainty.

https://www.bipm.org/en/doi/10.59161/jcgm100-2008e

### A39 — UNECE UN Regulation No. 156

Software-update and software-update-management requirements for applicable road-vehicle contexts.

https://unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update

### A40 — EU Battery Regulation 2023/1542

Individual battery passports, use-derived data, state of health, repurpose lineage, access control and interoperable open-format requirements.

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32023R1542

### A41 — Asset Administration Shell

Industrial Digital Twin Association specifications for metamodel, APIs, data specification, security and AASX packaging.

https://industrialdigitaltwin.org/en/content-hub/aasspecifications

### A42 — ISO 23247 digital-twin framework

Digital-twin general principles for manufacturing; useful as a mapping signal for synchronized representations and digital threads.

https://www.iso.org/standard/75066.html

### A43 — RFC 8785 JSON Canonicalization Scheme

Deterministic JSON representation for hashing and signing, subject to a strict numeric and parser profile.

https://www.rfc-editor.org/rfc/rfc8785.html

### A44 — CloudEvents

A common event-transport envelope; useful between services but not a replacement for RTracer's canonical record.

https://github.com/cloudevents/spec

### A45 — NIST Cybersecurity Framework

Risk-governance framework for identifying, protecting, detecting, responding and recovering across product and platform operations.

https://www.nist.gov/cyberframework

### A46 — NASA configuration management

Baseline, change, deviation/waiver, status accounting, audit and historical configuration principles.

https://www.nasa.gov/reference/6-5-configuration-management/

### A47 — FIVA Charter of Turin

Historic-vehicle preservation, conservation, repair and restoration principles, including documentation and marking of replacement material.

https://www.fiva.org/storage/Documents/Culture%20and%20Youth%20Commission/BOOK_Charter%20of%20Turin_web%20version.pdf

### A48 — IMO in-water cleaning guidance

Planning, inspection, coating protection, record-keeping and reporting guidance for cleaning ship biofouling in water.

https://wwwcdn.imo.org/localresources/en/OurWork/Environment/Documents/Biofouling%20pages/MEPC.1-Circ.918%20-%20Guidance%20On%20In-Water%20Cleaning%20Of%20Ships%27%20Biofouling%20%28Secretariat%29.pdf

### A49 — EASA continuing-airworthiness rules

Component serviceability, unsalvageable disposition, maintenance data and release patterns for aviation domain-pack adapters.

https://www.easa.europa.eu/en/document-library/easy-access-rules/online-publications/easy-access-rules-continuing-airworthiness

### A50 — ISO 1585 engine net power

A standardized road-vehicle engine net-power test context, reinforcing the need to preserve measurement location, setup and correction basis.

https://www.iso.org/standard/70078.html

### A51 — RFC 9562 UUIDs

Current IETF UUID formats, including time-ordered UUID version 7; useful for opaque sortable identifiers without embedding VIN, MAC, owner or location semantics.

https://www.rfc-editor.org/info/rfc9562/

### A52 — RFC 9421 HTTP Message Signatures

A method for signing selected HTTP message components; useful for transport integrity while remaining separate from record proofs and authorization.

https://www.rfc-editor.org/info/rfc9421/

### A53 — RFC 9457 Problem Details for HTTP APIs

A standard problem-response format on which RTracer can layer stable codes, validation stage, safe context and retry semantics.

https://www.rfc-editor.org/rfc/rfc9457.html

### A54 — RFC 8949 CBOR

A compact binary data representation suited to constrained devices and deterministic interchange profiles when paired with strict schema and canonicalization rules.

https://www.rfc-editor.org/rfc/rfc8949.html

### A55 — RFC 9052 COSE

CBOR Object Signing and Encryption structures for signed or encrypted compact device records and manifests.

https://www.rfc-editor.org/rfc/rfc9052.html

### A56 — RFC 9530 HTTP Digest Fields

HTTP content and representation digest fields for transport-integrity checks; these do not replace the canonical semantic-record digest.

https://www.rfc-editor.org/rfc/rfc9530.html

### A57 — OpenAPI Specification

Official HTTP API description family used to publish versioned developer contracts subordinate to the semantic schema registry.

https://spec.openapis.org/oas/

### A58 — AsyncAPI 3.0

Official event-driven API description specification for channels, operations, messages and bindings; useful for the at-least-once event surface.

https://www.asyncapi.com/docs/reference/specification/v3.0.0

### A59 — W3C Trace Context

Cross-service trace propagation. Trace identifiers aid operations but never become domain identity, authorization or canonical provenance.

https://www.w3.org/TR/trace-context/

### A60 — OpenTelemetry specifications

Vendor-neutral telemetry and OTLP signals for platform observability; operational telemetry is kept distinct from vehicle lifecycle telemetry.

https://opentelemetry.io/docs/specs/

### A61 — Apache Parquet file format

Columnar storage format used as an implementation option for high-volume telemetry segments with explicit RTracer manifests and schema locks.

https://parquet.apache.org/docs/file-format/

### A62 — Apache Arrow columnar format

Language-independent in-memory columnar representation useful for telemetry interchange and analysis without redefining channel semantics.

https://arrow.apache.org/docs/format/Columnar.html

### A63 — NIST SP 800-162 attribute-based access control

ABAC definition and considerations supporting subject, object, action, purpose and environment policy decisions.

https://csrc.nist.gov/pubs/sp/800/162/upd2/final

### A64 — NIST SP 800-207 Zero Trust Architecture

Continuous, resource-specific authorization principles supporting short-lived grants, explicit policy decisions and no ambient trust based on network location.

https://csrc.nist.gov/pubs/sp/800/207/final

### A65 — RFC 3339 date and time on the Internet

Timestamp lexical reference. RTracer adds explicit time-scale, precision, clock-domain and uncertainty semantics rather than treating a printed timestamp as measurement simultaneity.

https://www.rfc-editor.org/rfc/rfc3339.html

### A66 — RFC 8032 Edwards-curve signatures

Ed25519/Ed448 algorithm definitions supporting a pinned proof suite where deployment policy permits them.

https://www.rfc-editor.org/rfc/rfc8032.html

### A67 — RFC 8446 TLS 1.3

Modern transport-security protocol used under application-layer identity, proof, authorization and record-integrity controls.

https://www.rfc-editor.org/rfc/rfc8446.html

### A68 — RFC 9700 OAuth 2.0 Security Best Current Practice

Current OAuth security guidance, including audience restriction and sender-constrained access tokens for high-value APIs.

https://www.rfc-editor.org/rfc/rfc9700.html

### A69 — RFC 9449 Demonstrating Proof of Possession

DPoP binds an OAuth token presentation to an asymmetric key and HTTP request, reducing replay of stolen bearer material.

https://www.rfc-editor.org/rfc/rfc9449.html

### A70 — RFC 8705 OAuth mutual TLS

Certificate-bound token and mutual-TLS profiles for workload/provider integrations requiring proof of possession.

https://www.rfc-editor.org/rfc/rfc8705.html

### A71 — RFC 9396 OAuth Rich Authorization Requests

Structured authorization details that inform exact action, resource, amount and beneficiary bindings; RTracer's canonical grants remain the authority source.

https://www.rfc-editor.org/rfc/rfc9396.html

### A72 — W3C Web Authentication Level 3

Phishing-resistant public-key credentials and user-verification signals for human authentication and consequential confirmations.

https://www.w3.org/TR/webauthn-3/

### A73 — SPIFFE X.509-SVID

Short-lived workload identity profile useful for mutually authenticated service boundaries without ambient network trust.

https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md

### A74 — UCUM

Machine-oriented unit syntax and semantics used as a mapping source while RTracer separately locks quantity kind, dimension, representation and uncertainty.

https://ucum.org/ucum

### A75 — Protocol Buffers encoding

Official encoding documentation notes that serialization order and stability are not canonical guarantees; protobuf bytes are therefore not the portable signature representation.

https://protobuf.dev/programming-guides/serialization-not-canonical/

### A76 — Apache Iceberg specification

Snapshot, schema/partition evolution and table metadata concepts supporting rebuildable high-volume telemetry analytics above immutable source manifests.

https://iceberg.apache.org/spec/

### A77 — PostgreSQL transaction isolation

Serializable and repeatable-read behavior, retries and anomaly prevention supporting fenced stream append, auction close and budget reservation.

https://www.postgresql.org/docs/current/transaction-iso.html

### A78 — PostgreSQL row security policies

Database-enforced row filtering used as tenant defense in depth, never as the only application authorization boundary.

https://www.postgresql.org/docs/current/ddl-rowsecurity.html

### A79 — Open Policy Agent policy language

A policy-as-code reference for versioned deterministic authorization bundles and decision tests; deployments may use an equivalent engine with the same receipt semantics.

https://www.openpolicyagent.org/docs/policy-language

### A80 — W3C ActivityPub

Federated social-network client/server and server/server protocol used only through a public projection adapter.

https://www.w3.org/TR/activitypub/

### A81 — NIST SP 800-63-4 Digital Identity Guidelines

Current identity proofing, authentication and federation guidance informing assurance, recovery and authenticator policy.

https://csrc.nist.gov/pubs/sp/800/63/4/final

### A82 — SLSA specification 1.2

Software supply-chain provenance levels and build-integrity controls for services, registries, packs, migrations and connector artifacts.

https://slsa.dev/spec/v1.2/

### A83 — The Update Framework specification

Signed repository metadata, version/freeze/rollback resistance and delegated trust concepts for registry and software distribution.

https://theupdateframework.github.io/specification/latest/

### A84 — C2PA 2.4

Media provenance, assertions, ingredients and edit lineage. Provenance authenticates history of content bytes and operations, not truth of the depicted claim.

https://spec.c2pa.org/specifications/specifications/2.4/index.html

# Appendix B. Sixty-four adversarial edge TypeRecipes

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.appendix.b · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:10b747a2b9e78448edda71258af23707c2ce8113631594bd56b561be314ab162

The 407 core recipes in Section 12 prioritize broad onboarding coverage. These 64 additional cases deliberately stress rare support, propulsion, control, scale and transition combinations. Together the document supplies 471 named seed recipes while preserving the rule that an unnamed combination is still valid.

```text
Adversarial catalog rule
Each row must resolve through the same facets and graphs as an ordinary scooter or truck. Experimental maturity is a sourced assertion; conceptual mechanisms are not presented as certified, practical or commercially available.
```

### B1. Ground, rail, and contact-surface edge cases

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Mecanum autonomous mobile robot | Rigid floor; four wheels | Battery-electric independent angled-roller wheel vectors | Lateral translation without steering the wheel planes |
| Self-balancing monowheel | Road; single wheel contact | Electric wheel torque | Usable equilibrium is an actively controlled inverted pendulum |
| Spherical rolling robot | Floor/terrain; shell contact | Internal pendulum, flywheel or moving-mass reaction | Body shell is also the locomotion interface |
| Archimedes-screw vehicle | Snow, mud, sand and sometimes water; helical drums | Rotating helical surface reaction | Same interface reacts differently against solid mixture and liquid |
| Ice yacht | Ice runners + atmosphere | Wind sail plus runner lateral reaction | Ambient airflow supplies energy; runners supply side force |
| Magnetic wall crawler | Ferromagnetic wall/ceiling | Magnetic adhesion + wheel/track traction | Adhesion supplies support while traction supplies travel |
| Vibration bristlebot | Rigid surface; angled bristles | Eccentric vibration rectified by asymmetric friction | No conventional wheel, leg or fluid propulsor |
| Gravity racer | Sloped road; wheels | Gravity/elevation potential | Controllable mobile vehicle with no onboard propulsion converter |

### B2. Surface-water and air-water-interface edge cases

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Flettner-rotor ship | Water hull + atmosphere | Motor-spun rotor creates Magnus aerodynamic force | Rotor is an aerodynamic pressure surface, not a propeller |
| Wave glider | Surface float + submerged wing body | Tethered wings rectify wave-relative motion | Two-body propulsion path spans surface and submerged domains |
| Sidewall surface-effect ship | Water surface; cushion bounded by immersed sidewalls | Propeller or waterjet | Air cushion differs from free wing-in-ground aerodynamic lift |
| Wing-in-ground craft | Atmosphere near water/ground | Air propeller or jet | Aerodynamic ground-effect support without a trapped cushion |
| Human hydrofoil bicycle | Water; hull/float at rest, foils at speed | Pedal-driven propeller or oscillating foil | Support path changes from buoyancy to hydrodynamic lift |
| SWATH vessel | Water; submerged buoyant hulls and narrow struts | Marine propellers | Hydrostatic support with intentionally small waterplane area |
| Oscillating-fin surface robot | Surface-water hull | Reciprocating foil | Oscillatory rather than rotating water-momentum exchange |
| Regenerative sailboat | Water hull + atmosphere | Sail propulsion; trailing propeller can generate electricity | One propulsor reverses role and becomes an energy harvester |

### B3. Underwater, pipe, and subsurface edge cases

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Variable-buoyancy underwater glider | Submerged; near-neutral buoyancy + wings | Buoyancy change converted to forward glide | No continuous propulsive thrust required |
| Profiling float | Submerged/surface water | Buoyancy cycling plus environmental drift | Drift and vertical profiles are mission-relevant locomotion |
| Benthic walking ROV | Seabed + surrounding water; legs | Leg contact impulses | Underwater machine supported by seabed rather than buoyancy alone |
| Serpentine AUV | Submerged; controlled buoyancy | Body undulation | Articulated hull supplies propulsion and steering |
| Supercavitating underwater vehicle | Generated gas cavity inside water | High-thrust propulsor | Deliberately creates multiphase envelope to reduce wetted drag |
| Magnetohydrodynamic craft | Conductive water; buoyant hull/body | Electromagnetic body force on liquid | Experimental force generation with no moving external propulsor |
| Inchworm pipe robot | Pipe interior; alternating radial anchors | Anchor-extend-anchor linear actuation | Sequential fixation is essential to translation |
| Percussive burrowing mole | Soil/regolith | Repeated impacts plus casing friction | Creates its path through the operating medium |

### B4. Heavier- and lighter-than-air edge cases

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Autogyro | Atmosphere; autorotating rotor | Separate propeller provides forward thrust | Rotor supplies lift but is not normally engine-driven |
| Compound gyrodyne | Atmosphere; rotor + wing | Powered rotor plus separate propulsor | Lift sharing changes continuously between rotor and wing |
| Tiltwing powered-lift aircraft | Atmosphere; thrust-borne hover + wing cruise | Wing and propulsors rotate together | Geometry transformation changes force orientation |
| Tailsitter VTOL | Ground + atmosphere | Thrust-borne vertical phase, wing-borne cruise | Whole-body reference orientation changes between modes |
| Cyclorotor aircraft | Atmosphere | Horizontal-axis rotating blades with cyclic pitch | Vectorable lift/thrust without tilting a conventional rotor disk |
| Ornithopter | Atmosphere; flapping wings | Motor or biological force drives oscillating wings | Unsteady wing motion creates lift and thrust |
| Roziere balloon | Atmosphere | Combined heated-air and lifting-gas buoyancy | Two aerostatic systems have different endurance/control roles |
| Hybrid airship | Atmosphere; buoyancy + dynamic/thrust support | Propellers/fans; control surfaces/vectoring | Intentionally combines aerostatic and aerodynamic/thrust lift |

### B5. Space, high-altitude, and field-interaction edge cases

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Solar-sail spacecraft | Vacuum/radiation field | Photon pressure on reflective membrane | No expelled propellant |
| Electrodynamic-tether spacecraft | Ionospheric plasma + planetary magnetic field | Current-carrying tether field interaction | Exchanges orbital/electrical energy through deployed structure |
| Electric sail / plasma brake | Solar wind or ionospheric plasma | Charged-tether interaction | Field-mediated propellantless force with maturity recorded |
| Aerobraking nanosatellite | Vacuum to rarefied atmosphere | Controlled atmospheric drag | Environmental transition intentionally removes orbital energy |
| Reaction-wheel satellite | Orbital free fall | Internal momentum exchange for attitude | Cannot change center-of-mass translation without external force |
| Ion-electric orbital tug | Vacuum | Electric acceleration of carried propellant | Electric propulsion still consumes reaction mass |
| Asteroid hopper | Low-gravity surface/vacuum | Leg/flywheel/thruster impulse then ballistic arc | Unsupported ballistic phase dominates travel |
| Rockoon assembly | Atmosphere to space | Balloon carry then rocket propulsion | Two separately identified vehicles form one staged mission assembly |

### B6. Tethered, infrastructure-driven, and biological edge cases

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Funicular | Inclined rail | Offboard cable tension, often counterbalanced | Energy converter is infrastructure-side |
| Suspended cable gondola | Atmosphere; carrying cable | Haul rope or onboard cable traction | Cable can separately provide support, guidance and propulsion |
| Cable-driven parallel platform | Bounded workspace; several tension cables | Coordinated winches | No single path or conventional vehicle heading |
| Tethered aerostat | Atmosphere; lift gas + tether | Winch/weather-vane behavior; usually no free propulsion | Lighter-than-air but not a free powered airship |
| Tethered kite power drone | Atmosphere + ground station | Aerodynamic kite force through controlled tether | May generate ground-station energy while flying |
| Rowing shell | Water + atmosphere; hull buoyancy | Human reciprocal oars | Oar is intermittent force generator and steering effector |
| Animal-drawn sled | Snow/ground; runners | External biological prime mover through harness | Animal is a rights-bearing actor/energy provider, never a component |
| Passive-dynamic walker | Downhill surface; alternating feet | Gravity plus passive geometry | Walking gait without powered joints |

### B7. RC and physical-model edge cases

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| 1/8 nitro buggy | Off-road; tires | Model fuel -> small ICE -> clutch/gears -> wheel traction | RC describes control, not propulsion or scale |
| Model submarine with ballast | Surface/submerged water | Electric propeller + ballast/dive planes | Scale craft has genuine pressure, buoyancy and control states |
| Rubber-band ornithopter | Atmosphere | Elastic store drives flapping wings | Storage and converter may be one simple mechanism |
| Control-line model aircraft | Atmosphere + physical-line constraint | Engine/motor + propeller | Lines constrain radius and transmit pitch command |
| Live-steam model locomotive | Miniature rail | Fuel -> boiler -> cylinders/rods -> wheels | Scale does not simplify the energy chain |
| RC hydrofoil sailboat | Water + air; hull/foil support | Sail; radio sail trim/rudder | Displacement, transitional and foil-borne support states |
| Model rocket glider | Atmosphere | Rocket boost then aerodynamic glide | Propulsion, control and recovery modes differ completely |
| Dual-mode road-rail model | Floor/road + model rail | Wheel traction with deployable rail guidance | Scale does not remove infrastructure compatibility |

### B8. Transformable and multi-asset hybrid edge cases

| Canonical recipe family | Support + domain | Propulsion / mobility agency | Decisive differentiator |
| --- | --- | --- | --- |
| Roadable aircraft | Road wheels -> aerodynamic lift | Shared or separate road/air propulsors | Road and flight modes need separate configurations/approvals |
| Amphibious screw vehicle | Snow/mud/water; helical drums + buoyancy | Rotating helical drums | One interface supplies cross-domain reaction differently |
| Wheel-leg robot | Terrain; wheels + articulated legs | Wheel torque and/or leg actuation | Locomotion mode changes without root-asset change |
| Wheel-to-track transformer | Terrain; selectable wheel/track support | Shared drivetrain | Contact topology and roles change by configuration |
| Foldable quadplane | Atmosphere; rotor hover + fixed-wing cruise | Electric lift rotors + cruise propulsor | Fold/deploy and rotor-to-wing transitions change inertia/control law |
| Self-reconfiguring modular swarm | Ground/structure; connected modules | Module rolling/crawling or aggregate motion | Formation can become a load-bearing temporary body |
| Carrier UAV with ground rover | Air + ground; carried/deployed | Independent UAV and rover propulsion | Carrier-payload assembly never permanently merges identities |
| Inflatable planetary rover | Planetary surface; stowed then inflated | Wheel/body deformation or traction drive | Dimensions, stiffness and inertia change radically across deployment |

# Appendix C. Fifty adversarial conformance fixtures

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.appendix.c · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:ac6133ea77f03a177bceb65959d1c638291f489f95c7040d408d3d42e45b99b6

These fixtures are executable acceptance cases for the kernel and domain packs. Each requires an expected validation disposition and explanation graph. A structurally valid but surprising physical claim is usually retained with a warning; malformed, equivocal or unauthorized effects are rejected or quarantined.

### C1. Identity, time, and claims

| ID | Fixture | Expected result |
| --- | --- | --- |
| C-001 | Two assets claim the same VIN | Retain both opaque identities; create conflict; never auto-merge |
| C-002 | One recycled MAC appears on three controllers | Accept identifier history; infer no vehicle identity |
| C-003 | Normalizer collapses two case-sensitive serials | Reject mapping/normalizer; retain exact source values |
| C-004 | Full-size VIN attached to 1/8 replica | Reject namespace assignment; preserve represents/scale relation |
| C-005 | Frame replaced after collision | Require explicit continuity decision and donor/disclosure history |
| C-006 | Offline observation arrives six months late | Accept distinct valid/asserted and recorded times |
| C-007 | Same record ID/key, different canonical bytes | Quarantine equivocation and alert |
| C-008 | Circular supersession chain | Reject relation graph |
| C-009 | Authentic signature from untrusted issuer | Integrity valid; proposition trust unresolved |
| C-010 | Owner and registry disagree on model year | Retain conflict; projection explains policy choice |

### C2. Configuration, interfaces, and mechanisms

| ID | Fixture | Expected result |
| --- | --- | --- |
| C-011 | Exclusive component installed in two assets at once | Conflict/reject configuration until effectivity resolved |
| C-012 | Chassis contains itself through nested placement | Reject physical composition cycle |
| C-013 | Regenerative energy loop | Allow in energy graph with typed reversible edges |
| C-014 | Fuel port connected to electrical-power port | Reject dimensional/interface incompatibility |
| C-015 | Software deployment lacks target controller instance | Reject realized configuration |
| C-016 | Robot joint moves continuously | Operational-state update; no configuration explosion |
| C-017 | Smart trailer passive in one mode, torque-contributing in another | Allow separate mode/capability/control records |
| C-018 | Propeller car mislabeled wheel-driven | Retain wheels as support/steering; force generator reacts against air |
| C-019 | Reaction wheel claimed to translate satellite | Reject derived physical mechanism claim |
| C-020 | Blimp helium top-up modeled as component installation | Require material quantity event and purity/source |

### C3. Lifecycle, telemetry, tests, and evidence

| ID | Fixture | Expected result |
| --- | --- | --- |
| C-021 | Two traceable fuel lots blended in tank | Create mixture provenance and quantity balance |
| C-022 | Wash task exposes paint crack | Care succeeds; independent defect/finding opens |
| C-023 | Wheel dyno power compared with corrected crank power | Reject direct equivalence/comparison |
| C-024 | Observation uses expired calibration | Retain with quality warning and calibration status |
| C-025 | Telemetry chunks arrive out of order | Order by producer sequence/time model; preserve arrival order |
| C-026 | Same chunk index with different digest | Quarantine collision/equivocation |
| C-027 | Synthetic image submitted as raw observation | Reject truth-lane assignment; preserve as creative artifact |
| C-028 | Valid content credential from unknown signer | Provenance binding valid; trust unresolved |
| C-029 | Restoration uses reproduction body panels | Mark reproduction parts; retain original substance/history |
| C-030 | Salvaged part reused with carbon claim | Require allocation method and prevent double counting |

### C4. Control, privacy, and vehicle agent

| ID | Fixture | Expected result |
| --- | --- | --- |
| C-031 | Design supports autopilot but hardware absent | Capability designed, not realized |
| C-032 | Installed capability fails self-test | Realized but unavailable |
| C-033 | Available capability has expired grant | Deny engagement/execution |
| C-034 | Handover offered but never accepted | Existing authority remains; no completed transfer |
| C-035 | Equal-priority controllers lack arbitration | Reject control configuration |
| C-036 | Weather exits validated operating domain | Transition availability and execute named fallback |
| C-037 | Social agent emits a braking-command string | Treat as inert text; zero physical effect |
| C-038 | Public query requests live GPS | Deny or return delayed/coarsened projection |
| C-039 | Vehicle sold but persona voice license stays with seller | Deactivate/re-scope agent; no automatic transfer |
| C-040 | Service note contains prompt injection | Store as inert evidence text; fixed skills unaffected |

### C5. Commerce, registry, migration, and federation

| ID | Fixture | Expected result |
| --- | --- | --- |
| C-041 | Appraisal submitted as auction bid | Reject record-type substitution |
| C-042 | Bid arrives after trusted closing time | Reject for winner projection; retain audit record |
| C-043 | Bid lacks currency | Reject structurally |
| C-044 | Reserve changes after opening without permitted policy | Reject or require authorized auction restart |
| C-045 | Highest bidder is ineligible | Select next eligible bid under policy |
| C-046 | Settlement lacks current sale authority | Deny settlement; retain attempted action evidence |
| C-047 | Registry provider times out | Record unavailable; never project notFound |
| C-048 | Registry response exceeds freshness policy | Retain with stale warning; do not silently refresh value |
| C-049 | Lossy schema migration has no loss manifest | Reject migration activation |
| C-050 | Client cannot interpret private pack extension | Preserve and round-trip unchanged with schema/digest |

# Appendix D. Reference persistence contracts and canonical examples

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.appendix.d · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:f5fadeefc18b86bc513a575546d656b2ebc312cd8d6c79723b977d7c0949d01a

This appendix is an executable design sketch, not a mandate for one database product. Types and indexes may differ by deployment, but the invariants, separation of semantic meaning from admission metadata, and replay behavior are normative for the reference implementation profile.

### D1. Minimal relational ledger skeleton

```text
Reference SQL - compact v1.4 ledger skeleton
CREATE TABLE entity_root (
  tenant_id uuid, entity_id uuid, entity_kind text, created_record_id uuid,
  PRIMARY KEY(tenant_id,entity_id));

CREATE TABLE stream_head (
  tenant_id uuid, stream_id uuid, logical_shard_id text,
  last_stream_seq bigint, last_record_digest bytea, writer_epoch bigint,
  PRIMARY KEY(tenant_id,stream_id));

CREATE TABLE shard_head (
  ledger_id uuid, tenant_id uuid, logical_shard_id text, chain_epoch bigint,
  last_commit_sequence bigint, last_receipt_digest bytea, publisher_epoch bigint,
  shard_map_version text,
  PRIMARY KEY(ledger_id,tenant_id,logical_shard_id,chain_epoch));

CREATE TABLE record_ledger (
  ledger_id uuid, tenant_id uuid, logical_shard_id text, chain_epoch bigint,
  commit_sequence bigint, stream_id uuid, stream_sequence bigint,
  record_id uuid, canonical_bytes bytea, record_digest bytea,
  PRIMARY KEY(ledger_id,tenant_id,logical_shard_id,chain_epoch,commit_sequence),
  UNIQUE(tenant_id,record_id), UNIQUE(tenant_id,stream_id,stream_sequence));

CREATE TABLE idempotency_binding (
  tenant_id uuid, principal_id uuid, operation_family text,
  idempotency_key text, request_digest bytea, receipt_id uuid, status text,
  PRIMARY KEY(tenant_id,principal_id,operation_family,idempotency_key));

Outbox and projection checkpoints share the contiguous commit prefix.
Section 34 and Appendix O are normative for complete columns and constraints.
```

- Canonical bytes are retained exactly as digested; parsed convenience columns are indexes, never an alternate source of meaning.

- Foreign keys may be deferred or represented as typed unresolved references because evidence can arrive before the referenced entity is known.

- Proofs, subjects, relations, artifacts and receipts use child tables keyed by immutable record or receipt IDs; they never overwrite RecordCore.

- Tenant sequence allocation and stream-head advance occur in the same transaction as the ledger/outbox insert.

### D2. Four distinct signed and operational objects

```text
Semantic, cryptographic, admission and projection separation
RecordCore {                         ProofRecord {
  recordId, recordType, schemaRef,       proofId, recordId, recordDigest,
  subjectRefs[], validTime?, body        proofPurpose, verificationMethod,
}                                         createdAt, signatureBytes
                                        }

IngestReceipt {                       ProjectionReceipt {
  receiptId, recordId, tenantId,        projectionId, projectionVersion,
  receivedAt, recordedAt, ledgerSeq,    inputLedgerRange, inputDigests[],
  streamId, streamSeq, writerEpoch,      policy/schema/packLock,
  canonicalDigest, priorDigests[],       outputDigest, checkpoint,
  policyDecisionId, idempotencyBinding   generatedAt, derivationFindings[]
}                                      }

Signature target = canonical RecordCore bytes or a named manifest digest.
Operational receipt fields are never inserted into RecordCore after signing.
```

### D3. Configuration snapshot and diff

```text
Exact build state and explicit change
ConfigurationSnapshot {
  configurationId: "urn:rtracer:configuration:kun:2026-07-22T10:00Z",
  assetId: "urn:rtracer:entity:kun",
  validInterval: {from: "2026-07-22T10:00:00Z"},
  itemInstances: ["...engine", "...gearbox", "...rear-axle", "...tracker"],
  portInstances: ["...engine.output", "...gearbox.input", "...tracker.can"],
  connections: [{fromPort: "...engine.output", toPort: "...gearbox.input",
                 medium: "mechanicalRotation", state: "connected"}],
  softwareSet: [{component: "...tracker", releaseDigest: "sha256:..."}],
  calibrationSet: ["urn:rtracer:calibration:tracker:..."],
  sourceRecordIds: ["urn:rtracer:record:inspection:..."]
}

ConfigurationDiff {
  beforeConfigurationId, afterConfigurationId,
  addedItems[], removedItems[], replacedItems[],
  connectionChanges[], softwareChanges[], calibrationChanges[],
  authorizingChangeRecordId, executionRecordIds[], verificationRecordIds[]
}
```

### D4. Telemetry segment manifest

```text
Raw bytes remain interpretable and auditable
SegmentManifest {
  segmentId, captureSessionId, sourceDeviceId, configurationId,
  artifactDigest, byteLength, encoding, compression,
  channelSchemaRef, channelSchemaDigest,
  sequenceStart, sequenceEnd, sampleCount,
  clockDomains[{clockId, kind, nominalRate, wrapRule}],
  timeMappings[{fromClock, toClock, model, parameters, uncertainty}],
  observedStart, observedEnd, receivedAt,
  quality{gaps[], duplicates[], saturation[], invalidRanges[], flags[]},
  calibrationRefs[], privacyClass, retentionClass, rightsRef
}
```

### D5. Governed action transaction

```text
Conversation cannot bypass authorization or reconciliation
ActionProposal {
  actionId, agentId, personaVersion, principalId, beneficiaryId,
  actionKind, canonicalParameters, evidenceCheckpoint,
  requestedProvider, riskTier, requestedAt, proposalDigest
}
ActionGrant {
  grantId, principalId, agentId, allowedActionKinds[], resourceScope,
  purpose, moneyLimits?, confirmationRule, validInterval, grantEpoch
}
ActionReceipt {
  actionId, proposalDigest, policyDecisionId, grantId, grantEpoch,
  confirmationArtifactId?, providerOperationId?, providerReceipts[],
  state, startedAt?, reconciledAt?, resultRecordIds[], compensationIds[]
}

State path: PROPOSED -> EVALUATED -> CONFIRMED? -> RESERVED? -> EXECUTING
            -> SETTLED | REJECTED | FAILED | UNKNOWN_EFFECT -> RECONCILING
            -> SETTLED | COMPENSATED | OPERATOR_REQUIRED
```

### D6. Auction close and settlement lock

```text
Serialized winner decision; explicit settlement saga
AuctionCloseReceipt {
  auctionId, auctionVersion, trustedCloseTime, closePolicyDigest,
  sellerAuthorityRecordId, eligibleBidRecordIds[], excludedBidFindings[],
  reserveDisposition, winnerBidId?, closingPrice?, currency,
  decisionEngineVersion, closeDigest
}

SettlementSaga {
  settlementId, closeReceiptId, buyerId, sellerId, beneficiaryId,
  titleIdentityChecks[], inspectionDecision?, paymentIntentId?, escrowId?,
  taxAndFeeQuoteId?, transferDocumentIds[], custodyHandoffId?,
  personaRightsDispositionId?, states[], compensations[], finalReceiptId?
}

Only the close receipt selects a winner. A feed rank, notification order,
payment arrival, appraisal or later higher offer cannot replace that decision.
```

# Appendix E. One hundred twenty-four implementation conformance fixtures

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.appendix.e · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:2101c3aed540ea17d7f01248adc9910e7b7e1301269958c5812525760eda4b35

These fixtures are release-gate requirements for the implementation-depth profile. Each must have a machine-readable input, expected acceptance/rejection and canonical finding code; stateful cases also require before/after ledger, stream-head, projection and connector receipts. The table states the semantic oracle, not only a UI message.

### E1. Envelope, parsing, and canonicalization

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-001 | JSON object repeats a key with two values | Reject during parsing; no digest, proof or idempotency binding is created. |
| T-002 | Equivalent object arrives with different key order and whitespace | Canonical bytes and record digest match exactly. |
| T-003 | Number 1.0 is sent where the schema requires an exact decimal string | Reject the wire form; never silently coerce binary floating point. |
| T-004 | Unicode identifier uses a visually confusable character | Preserve exact source, apply declared normalization only to indexed alias, and flag confusable risk. |
| T-005 | Unknown top-level field appears outside the extension container | Reject under the locked schema version; do not drop it silently. |
| T-006 | Known extension namespace contains an unknown future member | Preserve and round-trip according to extension policy without claiming understanding. |
| T-007 | Payload exceeds the record-class byte/depth limit | Reject before full allocation and return a safe structured limit error. |
| T-008 | Content-Type names schema v3 while schemaRef names v2 | Reject before canonicalization as an envelope/schema mismatch. |
| T-009 | Canonical CBOR and canonical JSON encode the same conceptual claim | Treat as distinct signed representations unless a declared cross-format semantic digest profile applies. |
| T-010 | Client signs pretty JSON instead of canonical RecordCore bytes | Proof verification fails with the exact signature-target profile identified. |

### E2. Identity, references, and bitemporal semantics

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-011 | VIN is submitted as the internal entity primary key | Reject model misuse; create an opaque entity ID and a scoped identifier assertion. |
| T-012 | Two physical assets present the same plate number at different valid times | Retain both scoped assertions; no entity merge follows from the plate alone. |
| T-013 | One tracker MAC address is moved from KUN to another truck | Close the installation relationship; preserve device identity and both configuration histories. |
| T-014 | A record references a part not yet present locally | Admit a typed unresolved reference if policy allows; projection marks incomplete instead of inventing the part. |
| T-015 | Later evidence says two entity roots are the same | Append a merge/same-as decision with authority and reversible projection; never rewrite old record subjects. |
| T-016 | A mistaken merge is discovered after social followers accumulated | Append split correction, reproject provenance-aware followers/content, and expose continuity decisions. |
| T-017 | Maintenance occurred Monday but was recorded Friday | validTime represents Monday; recordedAt remains Friday and cannot be backdated. |
| T-018 | A registry fact was valid in 2024 but first learned in 2026 | As-valid and as-known queries return different, explainable results. |
| T-019 | Valid intervals overlap with mutually exclusive custody assertions | Retain both claims, emit conflict assessment, and avoid a fabricated single owner. |
| T-020 | Entity is deleted from public view | Public projection disappears under policy while non-public append-only evidence follows lawful retention/deletion rules. |

### E3. Claims, evidence, quantities, and coordinates

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-021 | Signed owner statement says mileage is 80,000 km | Authenticate the issuer/source; do not upgrade the value to measured truth. |
| T-022 | Two odometers disagree with different calibration histories | Retain both observations, uncertainties and calibration refs; derive a qualified assessment. |
| T-023 | Power value lacks measurement location | Reject or mark incomplete; engine, wheel and shaft power cannot be compared implicitly. |
| T-024 | Dyno result omits correction standard and atmosphere | Retain raw artifact as evidence but prohibit normalized comparison claim. |
| T-025 | Torque series uses N·m and lbf·ft | Convert only through exact unit definitions while preserving original values and uncertainty. |
| T-026 | Mass is given as 2.5 without unit | Reject as semantically incomplete; field-name convention does not supply a hidden unit. |
| T-027 | GNSS point omits datum/frame | Mark coordinate uninterpretable for precision use; no silent WGS84 assumption. |
| T-028 | Pose uses quaternion with norm far from one | Reject or normalize only under an explicit transform receipt with error bound. |
| T-029 | Derived lap time has no input segment IDs | Reject as an authoritative metric; keep as ungrounded analysis if allowed. |
| T-030 | Correction retracts one evidence item used by a published claim | Recompute assessment/projections and issue correction obligations without deleting original lineage. |

### E4. Configuration, topology, parts, and lifecycle

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-031 | Configuration contains the same serialized battery instance twice | Reject duplicate occupancy unless the model explicitly represents a composite/alias. |
| T-032 | Fuel hose is connected to an electrical power inlet | Reject graph validation by port family, medium and direction constraints. |
| T-033 | Mechanical shaft connection exceeds declared speed/torque envelope | Reject verified-ready state or require an explicit engineering waiver. |
| T-034 | Propeller is mounted but no energy/conversion path reaches it | Configuration may exist physically; propulsion capability evaluates false/indeterminate with explanation. |
| T-035 | RC battery is swapped between heats | Create a new configuration snapshot/diff while preserving the same vehicle root. |
| T-036 | Software update changes autonomous behavior with no hardware change | Record software/calibration configuration diff and re-evaluate control capabilities. |
| T-037 | Part is removed for service then reinstalled | Represent two installation intervals; do not clone or reset the part identity. |
| T-038 | Replacement component has unknown serial | Create a bounded anonymous item instance linked to source evidence and later reconciliation. |
| T-039 | Modification record has after-state but no before configuration | Reject completion or mark change lineage incomplete; current state cannot prove the delta. |
| T-040 | Wash photos are timestamped but not tied to configuration/condition | Store media, but condition and appearance projections remain qualified until contextual links exist. |

### E5. Schema registry, proofs, idempotency, and projections

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-041 | Schema reference resolves to mutable latest URL | Reject canonical admission; require immutable version and digest lock. |
| T-042 | Registry serves bytes whose digest differs from lock | Quarantine registry integrity failure and halt dependent validation. |
| T-043 | Signing key was valid at proof creation but is revoked now | Verify historical key status at proof time and expose current revocation separately. |
| T-044 | Proof signs a record digest using an unapproved algorithm | Reject proof profile while retaining the unsigned record according to admission policy. |
| T-045 | Exact idempotent retry arrives after client timeout | Return the original immutable result and receipt without a second append. |
| T-046 | Same idempotency key carries different request digest | Quarantine equivocation and never choose one payload silently. |
| T-047 | Projection replay uses the same inputs and lock set | Output canonical digest and checkpoint match the golden result. |
| T-048 | Projection code changes but version remains unchanged | Release gate fails; code digest/version must change before activation. |
| T-049 | Poison event causes repeated consumer crash | Quarantine the projection generation, expose degraded state, and prohibit silent skip. |
| T-050 | Explanation contains a private source edge for a public view | Redact the edge and prove non-interference while preserving internal derivation. |

### E6. Ledger concurrency, outbox, and replay failure

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-051 | Two writers append with the same expected stream sequence | Exactly one commits; the other receives a concurrency conflict and new tail. |
| T-052 | Old cell resumes after failover with expired writer epoch | Fence and reject every append regardless of its local lease belief. |
| T-053 | Process crashes after ledger insert but before commit | Transaction rolls back record, head and outbox together. |
| T-054 | Process crashes after commit before publishing outbox | Publisher later emits the durable outbox row; no semantic write is lost. |
| T-055 | Broker delivers the same change event five times | Consumer applies one deterministic result and advances checkpoint once. |
| T-056 | Events from independent streams arrive in different orders | Each stream remains valid; cross-stream projection exposes contributing checkpoints. |
| T-057 | Event N+1 arrives before N within an ordered partition | Buffer/retry until gap resolves or enter declared degraded state; never invent N. |
| T-058 | Hash-chain predecessor digest does not match stream head | Reject append and raise integrity incident. |
| T-059 | Backup restore omits one committed ledger segment | Digest/sequence scrub detects gap before service promotion. |
| T-060 | Full replay differs from incremental projection | Fail release/recovery gate and preserve both outputs for deterministic root-cause analysis. |

### E7. Telemetry, media, clocks, and derived data

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-061 | Telemetry segment sequence range overlaps prior segment | Detect duplicate/overlap; deduplicate only by declared sample identity and retain finding. |
| T-062 | Device clock wraps mid-capture | Apply declared wrap rule and preserve mapping uncertainty. |
| T-063 | GNSS clock jumps backward after loss of fix | Split time mapping or flag discontinuity; never force monotonic observed time silently. |
| T-064 | Channel schema digest changes inside one segment | Reject segment or split at the change; one manifest binds one schema. |
| T-065 | Upload byte digest differs from manifest | Reject admission, retain safe failure receipt, and prohibit derived metrics. |
| T-066 | Sample count is correct but sequence contains gaps | Admit under policy with explicit gap ranges and quality disposition. |
| T-067 | Sensor saturates during dyno peak | Flag invalid/censored interval; peak result cannot be presented as fully observed. |
| T-068 | Photo EXIF conflicts with trusted capture receipt | Retain both sources and conflict; do not overwrite one timestamp. |
| T-069 | AI-generated car image is posted as documentary evidence | Require synthetic lineage and creative-lane label; exclude from factual condition proof. |
| T-070 | Derived braking metric uses a retracted calibration | Invalidate/recompute affected derivation and propagate correction to public claims. |

### E8. Tenancy, cache, search, deletion, and disaster recovery

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-071 | Artifact bytes deduplicate across tenants | Share physical bytes only if designed, but keep independent authorization, encryption and lifecycle envelopes. |
| T-072 | Public cache key omits audience disclosure class | Security test fails; cache construction is rejected. |
| T-073 | Search count changes when a private vehicle is added | Non-interference test fails; private existence must not leak through count/ranking/timing. |
| T-074 | Profile request asks for checkpoint newer than projection | Wait within budget, route to authoritative read or return explicit staleness—not false freshness. |
| T-075 | Owner revokes precise-location sharing | Priority propagation removes/replaces precise views and invalidates affected caches. |
| T-076 | Retention expires raw telemetry used by a public summary | Delete/dispose as required and mark future reproducibility limits on the retained summary. |
| T-077 | Legal hold is applied to one incident interval | Preserve only scoped records/artifacts under separate authority and review date. |
| T-078 | Regional replica violates residency policy | Block replication and emit governance/security incident. |
| T-079 | Key backup cannot decrypt restored artifact | Recovery test fails even if object bytes and digest are intact. |
| T-080 | Tenant export is restored on a clean implementation | Schemas, packs, records, proofs, artifacts and checkpoints reproduce portable dossier semantics. |

### E9. Principals, grants, policy, and action execution

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-081 | Profile administrator tries to sell the vehicle | Deny: profile administration does not imply sale authority. |
| T-082 | Owner grant expired one second before dispatch | Reevaluation denies dispatch despite earlier proposal approval. |
| T-083 | Confirmed ticket price changes before purchase | Invalidate confirmation and require a new exact-terms decision. |
| T-084 | Agent changes one bid digit after confirmation | Proposal digest mismatch denies execution and records attempted mutation. |
| T-085 | Grant permits merch purchase but connector requests ticket scope | Deny least-privilege scope mismatch. |
| T-086 | Mandate allows EUR 100 per action; cart totals EUR 100.01 | Deny before provider dispatch. |
| T-087 | Principal revokes grant while provider reservation is open | Stop new effects and follow declared release/settlement reconciliation for existing reservation. |
| T-088 | Agent text contains a steering command | Treat as inert content; no route exists to safety-control actuators. |
| T-089 | Policy engine is unavailable for R3 action | Fail closed and preserve proposal; do not use cached allow beyond its binding/validity. |
| T-090 | Connector timeout follows possible payment capture | Enter UNKNOWN_EFFECT and reconcile by stable provider operation ID before retry. |

### E10. Persona, content, rights, spotting, and privacy

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-091 | Vehicle agent states an unverified horsepower figure as fact | Grounding gate blocks or qualifies it with evidence state and source. |
| T-092 | Creative post lets KUN narrate feelings | Permit as declared persona fiction; never convert it into a mechanical condition claim. |
| T-093 | Sponsor requests undisclosed promotional speech | Deny or require explicit paid-content labeling and campaign receipt. |
| T-094 | Persona voice license expires while scheduled posts remain | Freeze affected voice outputs and require a valid replacement right. |
| T-095 | Truck is sold but persona rights remain licensed to seller | Separate asset transfer from persona succession and deactivate/re-scope representation. |
| T-096 | Spotter photo contains a visible child and plate | Apply people/plate privacy, rights and location policy before any public candidate profile. |
| T-097 | Image similarity finds two plausible famous cars | Keep candidate set and confidence; no automatic merge or owner notification claim. |
| T-098 | Invitation claimant proves custody but not ownership | Grant only the custody/profile functions justified by proof; do not assert title. |
| T-099 | Private interview source approves one excerpt only | Publish only the approved excerpt/context; retain source recording under scoped access. |
| T-100 | Advertisement model infers sensitive owner trait from vehicle | Prohibit inference and targeting; vehicle interest is not consent to human sensitive profiling. |

### E11. Listings, auctions, fraud, and settlement

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-101 | Asking price is displayed as highest bid | Reject projection-type substitution and retain distinct value objects. |
| T-102 | Bid is received after trusted close time but client timestamp is earlier | Reject eligibility based on trusted admission time while retaining audit evidence. |
| T-103 | Two equal bids arrive in one serialized auction stream | Apply declared deterministic tie rule using immutable bid receipts. |
| T-104 | Seller changes reserve after opening without allowed policy | Reject change or close/relist under explicit restart rules and bidder notice. |
| T-105 | Highest monetary bid is from an ineligible bidder | Exclude with finding and apply close policy to remaining eligible set. |
| T-106 | Fraud system flags account after bid admission but before close | Evaluate current eligibility under declared policy and preserve both admission and exclusion evidence. |
| T-107 | Feed ranking places a lower bid first | No effect on close; feed order is not auction order. |
| T-108 | Payment succeeds but title check fails | Settlement saga pauses/compensates according to escrow and refund terms; no asset transfer. |
| T-109 | Custody transfers while persona rights do not | Record independent custody/title/persona dispositions and avoid a bundled continuity fiction. |
| T-110 | Chargeback occurs after beneficiary payout | Append dispute, receivable/liability and recovery entries; posted journal history remains unchanged. |

### E12. Commerce, accounting, recruitment, and control isolation

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-111 | Journal entry debits and credits differ by one minor unit | Reject posting; no tolerance or floating-point rounding is permitted. |
| T-112 | One entry balances only after mixing EUR and CZK | Reject; balance independently per currency and record explicit FX transactions. |
| T-113 | Refund edits the original capture row | Reject mutation; append reversal/refund entries linked to the source. |
| T-114 | Vehicle revenue report treats escrow cash as earnings | Accounting projection fails classification; escrow liability remains separate. |
| T-115 | Revenue share omits fee and tax basis | Reject settlement calculation as under-specified. |
| T-116 | Event seat reservation expires before purchase | Reconcile release and require a new quote/reservation; do not capture stale terms. |
| T-117 | Merch provider sends duplicate fulfillment webhook | Deduplicate by provider event identity and preserve attempt metadata. |
| T-118 | Agent recommends internship using private telemetry contribution | Deny unless contributor consent and recruitment purpose explicitly cover the evidence. |
| T-119 | Vehicle popularity score is used to reject an engineering applicant | Prohibit high-impact decision from social rank; require dedicated human-reviewed process. |
| T-120 | Social runtime obtains network reachability to a CAN actuation gateway | Architecture/security conformance fails; planes must be isolated by capability and network boundary. |

### E13. Cross-domain capstone fixtures

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-121 | Fan-propelled bicycle has wheel support, air-thrust propulsion and human steering | Match the composed recipe without misclassifying fan as support or wheel as propulsion. |
| T-122 | Amphibious RC model leaves water, deploys wheels and swaps control mode | Bind each observation/action to configuration, medium, operation and function-scoped authority intervals. |
| T-123 | Blimp carries a robotic gripper while tethered, then flies remotely | Represent buoyant support, tether constraint, propulsive flight, manipulation utility and two operational configurations. |
| T-124 | KUN completes acquisition, wash, telemetry, service, modification, dyno, media, event purchase, sponsorship, auction and transfer | Every projection traces to immutable records; rights, money, persona and title transitions remain independent and replayable. |

# Appendix F. Full KUN implementation trace and cross-domain proof

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.appendix.f · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:ac1b025f8eb80ebd0ee7ed10876001c6e27837831af4976df6318493eee112fe

This trace shows how one physical truck becomes a durable vehicle identity, evidence dossier, social character, service history, telemetry source, governed commercial actor and transferable asset without collapsing those roles. Record names are illustrative; every step uses the canonical admission path and receives its own proof/admission/projection receipts where applicable.

### F1. KUN ‘Prague Workhorse’ — end-to-end lifecycle

| Step | Intent / physical effect | Canonical record families | Rebuildable product views |
| --- | --- | --- | --- |
| 01 | Enroll physical asset | EntityRootCreated; EntityKindAssertion | Private owner vault and empty vehicle profile shell |
| 02 | Assert VIN, registration and aliases | IdentifierAssertion × n; IssuerEvidence; ConflictAssessment? | Masked identifiers and registry-status view |
| 03 | Attach tracker/MAC | DeviceRoot; IdentifierAssertion; InstallationRelationship | Current connected-device inventory; MAC remains private |
| 04 | Declare authority | OwnershipClaim; CustodyClaim; ProfileAdminGrant; EvidenceAssessment | Role-specific dashboard; no role is inferred from another |
| 05 | Capture as-received build | Inspection; ConfigurationSnapshot; Item/Port/Connection records | Exact current-build graph and type-recipe matches |
| 06 | Create KUN persona | PersonaVersion; RepresentationGrant; RightsGrant; VoicePolicy | Public name, Prague Workhorse story and bounded voice |
| 07 | Wash and photograph | CareActivity; MediaArtifacts; CaptureReceipt; ConditionObservations | Wash timeline card and rights/privacy-safe gallery |
| 08 | Calibrate telemetry device | CalibrationRecord; SoftwareRelease; ClockCharacterization | Device-health/configuration view |
| 09 | Record Prague drive | CaptureSession; SegmentManifest × n; GNSS/clock mappings | Private route, delayed/coarsened public mission summary |
| 10 | Derive trip metrics | DerivationReceipt; MetricObservation; QualityAssessment | Distance, duration, energy/fuel and story-ready facts with lineage |
| 11 | Detect service need | ConditionAssessment; MaintenanceRequirement; DueProjection | Owner reminder; no public defect disclosure by default |
| 12 | Authorize and perform service | WorkOrder; Approval; Labor/PartConsumption; ServiceExecution | Maintenance history and cost/warranty views |
| 13 | Install modification | ChangeRequest; EngineeringAssessment; Execution; ConfigurationDiff | Before/after build, compatibility and new recipe matches |
| 14 | Verify modification | Inspection/TestRun; Finding; ReleaseToServiceDecision | Verified-current badge qualified by scope/date |
| 15 | Run dyno/test | TestPlan; SetupConfiguration; Environment; RawArtifact; Result | Comparable chart only when correction/location/uncertainty are complete |
| 16 | Generate KUN post | ContentRequest; RetrievalReceipt; Draft; GroundingMap; Approval | Persona narration with factual and creative lanes visibly separated |
| 17 | Publish and converse | PublicationReceipt; ConversationTurn; Moderation/Correction records | Vehicle-native feed and cited answer surface |
| 18 | Receive a spotting | SpottingObservation; CandidateResolution; RedactionReceipt | Delayed/coarsened spotting card; no identity merge |
| 19 | Invite claimant/community | Invitation; ClaimAttempt; VerificationDecision | Join/claim flow scoped to proven role |
| 20 | Recommend race/event | RecommendationReceipt; Explanation; Consent/Preference state | Relevant event card without sensitive-owner inference |
| 21 | Buy ticket or training | ActionProposal; Confirmation; GrantDecision; Provider/Order receipts | Entitlement in owner/team wallet; UNKNOWN_EFFECT if unresolved |
| 22 | Sell merch/sponsorship | Campaign; RightsApproval; Catalog/Order; JournalEntries; RevenueShare | Labeled sponsored content and balanced beneficiary economics |
| 23 | Create live listing | Appraisal; Listing; SellerAuthority; DisclosurePackage | Asking price and evidence-backed dossier, distinct from bids/value |
| 24 | Run auction | AuctionVersion; BidReceipts; EligibilityFindings; CloseReceipt | Serialized eligible-bid view and immutable winner/no-sale decision |
| 25 | Settle transfer | SettlementSaga; Payment/Escrow; Title/Custody Handoff | Transaction status, payout/refund and delivery views |
| 26 | Decide persona succession | PersonaTransfer/License/Retirement; New RepresentationGrant | Followers see an explicit continuity, fork or retirement—not hidden takeover |
| 27 | Revoke old access | GrantRevocations; Key/Device Rotation; Cache/Disclosure Invalidation | New owner views begin at authorized scope; historical facts keep provenance |
| 28 | Export and replay dossier | ExportManifest; Files/Digests; Import/Replay Receipts | Portable full-life narrative regenerated from records and artifact manifests |

### F2. One transaction expanded: KUN buys a race ticket

1. KUN's agent retrieves the public event, seat/price quote and the owner's current preferences through a purpose-bound projection.

1. It creates an inert ActionProposal containing the exact event, seat class, beneficiary, total currency/amount, provider and proposal digest.

1. The policy engine checks current principal authority, R3 risk, ticketing grant, period/action limits, jurisdiction, provider and conflict rules.

1. The owner confirms the exact canonical proposal. The confirmation artifact binds amount, terms, proposal digest, expiry and confirmation method.

1. Immediately before dispatch, policy reevaluates the unchanged proposal against the current grant epoch, mandate balance, quote validity and provider state.

1. The connector sends one operation with stable RTracer action ID and provider idempotency key. The local action becomes EXECUTING.

1. A provider success produces reservation/order/payment/entitlement records plus balanced journal entries and a final ActionReceipt.

1. A possible-effect timeout produces UNKNOWN_EFFECT. Reconciliation queries the provider before any retry and ends in SETTLED, COMPENSATED or OPERATOR_REQUIRED.

1. The social post ‘I’m going to the race’ can publish only after entitlement evidence exists; the post cites the safe projection, not payment secrets.

### F3. Cross-domain proof of the same substrate

| Asset | Differentiating composition | Same kernel records prove |
| --- | --- | --- |
| 1/8 electric RC buggy | ground contact wheels; battery → inverter → motor → drivetrain; radio/manual and stabilization by function | asset/device identity, battery configurations, heats, telemetry, crashes, repairs, setup sheets and driver/team attribution |
| fan-propelled bicycle | wheels support/steer; engine or electric motor drives a fan; thrust reacts against air | support and propulsion remain independent, so the machine is not forced into wheel-driven bicycle or aircraft categories |
| airboat | buoyant hull support; above-water air propeller; rudder/steering in air/water interaction | medium, force path, exposed hazard zones, propeller guard, mission and marine-registry adapter |
| submerged-propeller boat | buoyant hull; shaft/electric drive; propeller reacts against water | same boat domain with a different reaction medium, port topology, efficiency/test and maintenance records |
| remotely flown blimp | buoyant gas support; propellers for translation/yaw; control surfaces; optional tether | gas envelope, ballast, tether state, airspace operation, remote link, payload, weather envelope and flight records |
| rocket dragster | ground wheels support/guide; rocket impulse provides thrust; parachute/brakes stop | support is not propulsion; consumable motor, safety authority, test/run evidence and exact configuration are first-class |
| transforming road eVTOL | wheeled road mode, deployed lift/propulsion surfaces, flight mode and transition configuration | one entity across mutually constrained configurations, domain transitions, software/calibration and function-scoped authority |
| rail inspection robot | rail guidance/support, traction drive, sensor utility and optional manipulator | route/authority, maintenance, observations, work orders and robot-specific domain pack coexist without a new kernel |

### F4. Proof obligations before claiming ‘the vehicle lives’

- Every factual statement made by the vehicle resolves to evidence/assessment IDs and an as-of checkpoint; fiction and affect are explicitly persona expression.

- Every external action resolves to principal, beneficiary, current grant, policy decision, confirmation when required, provider receipt and reconciliation state.

- Every physical capability resolves to an exact configuration, support/propulsion/action paths, operating domain and function-scoped controller—not a marketing label.

- Every price/value surface identifies whether it is an appraisal, asking price, standing offer, eligible bid, close price or settled transaction.

- Every ownership, custody, profile, persona, media, telemetry and economic right has its own time-bounded authority record.

- Every public location/media view is a disclosure projection; raw precise data remains separately authorized and retention-controlled.

- Every derived profile/feed/search/market state can be destroyed and rebuilt from the ledger, artifacts, registry locks and deterministic projection versions.

# Appendix G. Exact wire, digest, append, event, and query reference vectors

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.appendix.g · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:e72b2ac270961e9cf8b298911f28f0145ad7d9b068b000b6a7e14177343e4e2d

These compact vectors make the prose testable. The maintained conformance repository must provide byte files, expected digests, detached proofs, SQL setup/teardown and multi-language runners. Ellipses in explanatory panels are not fixtures; executable vectors contain complete 64-hex digests and complete IDs.

### G1. Canonical JSON rejection and acceptance matrix

| Input difference | Canonical disposition | Reason |
| --- | --- | --- |
| object members arrive in another order | accept; canonical bytes sort members | member order has no semantic meaning under the JSON profile |
| set-valued subjects arrive in another order | accept; schema total-key sorts | the schema—not the field name—declares set semantics |
| ordinary array arrives reordered | different record or invalid | sequence semantics are preserved |
| duplicate JSON member | reject before object construction | parsers must not choose first/last value differently |
| internal canonical text is decomposed Unicode | reject | signed internal lexical form must already be canonical |
| external serial uses variant spacing/case | preserve sourceValue; optional attributed normalized derivation | source evidence is not silently rewritten |
| open interval includes end:null | reject | absence means open; JSON null is not a canonical union member |
| number is 1e3, +1, 01, -0 or NaN | reject | numeric lexical forms are closed and deterministic |
| unknown body field outside extension point | reject | closed schemas prevent accidental semantic drift |
| unknown namespaced extension with valid lock | accept and round-trip | extension preservation supports open-world growth |

```text
Reference verifier order
# byte-level verifier outline
raw = read_exact_bytes(limit=8_MiB)
obj = strict_parse(raw, reject_duplicate_keys=True, reject_invalid_utf8=True)
locks = registry.resolve_local(obj.schemaLock, obj.vocabularyLocks)
schema.validate_closed(obj)
lexical.validate_without_mutation(obj)
canonical = jcs_profile_1.serialize(obj, schema_set_sort_keys=locks.setKeys)
assert jcs_profile_1.serialize(strict_parse(canonical)) == canonical
recordDigest = sha256(b"RTRACER\x00RECORDCORE\x00v1.3\x00" + canonical)
verify_detached_proofs(recordDigest, current_trust_snapshot)

# never hash parsed dictionaries, ORM objects, protobuf messages, pretty JSON,
# database text, decompressed guesses or a projection as RecordCore bytes.
```

### G2. Admission race oracle

| Concurrent request pair | Permitted committed result | Client outcome |
| --- | --- | --- |
| same scoped idempotency key + same request digest | one record, one receipt, one outbox event | both receive original receipt; later response may be replay |
| same scoped key + different request digest | at most first request | other receives equivocation conflict and security finding |
| different keys + same recordId/digest | one unique record admission | other resolves duplicate record receipt or explicit conflict by profile |
| different keys + same stream expected sequence | one next sequence | loser receives expected-sequence conflict and reloads |
| old writer epoch + correct expected sequence | no append by stale writer | terminal fencing failure for that writer |
| outbox publish crashes after broker ack | one outbox row, possible duplicate deliveries | consumers converge by stable eventId |

### G3. Canonical record, receipt, event, and projection digest boundaries

| Changed fact | Digest that must change | Digest that must not change |
| --- | --- | --- |
| portable body or semantic field | record/body; downstream receipt/projection | unrelated records |
| detached signature added | ProofRecord/proof set | RecordCore digest |
| tenant, stream sequence or received time | admission receipt | portable RecordCore |
| broker retry or consumer offset | transport-operation telemetry only | canonical eventData, eventId, record and receipt |
| audience/policy/redaction/as-of time | projection digest/ETag | source records/receipts |
| object encryption nonce | encoded artifact/envelope digest | plaintext artifact digest |
| schema migration projection | new record/projection/migration receipt | historical source bytes |

### G4. Stateful API transcript requirements

1. Create two principals and two sender-bound credentials; prove that a token for service A fails at service B.

1. Append a record at expected stream sequence zero; verify canonical bytes, record digest, receipt digest, sequence one and outbox event.

1. Repeat the exact request after simulating a connection loss; obtain the same receipt and no second record/event.

1. Retry the key with one changed body byte; receive the equivocation code without revealing prior private body content.

1. Build public and owner projections at the same checkpoint; prove distinct projection digests and public non-interference after a private record is added.

1. Replay broker delivery twice; materialized view and checkpoint advance once while delivery metrics count both attempts.

1. Export the checkpoint-pinned dossier, verify every digest offline, import into another tenant as external assertions, and prove local grants/ownership are not copied.

# Appendix H. Normative invariants, state-transition matrices, and failure registry

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.appendix.h · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:a511aece418e0116dbab7844174bcb451d0e99164e64bcaac9eee3b5dc17bf95

This appendix collects cross-cutting rules that implementations must encode as constraints, transaction preconditions, property tests or deployment architecture—not merely reviewer knowledge.

### H1. Forty-four security and economic invariants

H-01  Asset, persona, principal, agent, device and provider identifiers are never interchangeable.

H-02  A vehicle is not a legal principal or account holder; an accountable principal and beneficiary bind every consequence.

H-03  VIN, plate, serial, MAC, transponder and image match never authenticate a principal.

H-04  Ontology, recipe match, graph inference and social relationship never create authority.

H-05  Explicit deny overrides permit; missing required policy attributes deny.

H-06  Revoked, expired, disputed or stale-epoch grants cannot dispatch.

H-07  Delegation only attenuates; R3/R4 selectors cannot be unbounded wildcards.

H-08  Every R3/R4 confirmation binds exact proposal, displayed terms, principal, credential, expiry and one-time nonce.

H-09  Proposal mutation invalidates confirmation, decision, reservation and rendered provider request.

H-10  The social agent has no schema, route, key or lease for physical actuation.

H-11  The model receives no provider, payment or signing credentials and no generic effect tool.

H-12  Untrusted content is inert; only typed post-model enforcement can create a proposal.

H-13  Every public factual claim has support or an exact qualifier; creative expression never becomes evidence.

H-14  Voice, likeness, media, mark, language, territory, channel and monetization rights are current at generation and publication.

H-15  Precise spotting location is private by default; repeated views cannot reconstruct a prohibited route.

H-16  Suppression does not leak through counts, timing, ranking, errors or different reporter responses.

H-17  Consent withdrawal stops new dependent processing and traces derivative remediation.

H-18  Legal holds are scoped, authorized, reviewed and do not themselves permit use.

H-19  Every external disclosure has a receipt naming projection, fields, purpose, recipient and duties.

H-20  Sponsored speech is disclosed; sensitive human traits are not inferred from vehicles for targeting.

H-21  Recruitment evidence is separately granted and social popularity is excluded from selection.

H-22  Bids are immutable and each admitted bid has trusted receive time and stream sequence.

H-23  Auction close is serialized; feed, notification or payment order never chooses the winner.

H-24  Seller/profile administrators cannot edit admitted bids or choose a reserve after opening.

H-25  Payment, custody, title, persona, profile, media and data rights transfer independently.

H-26  Regulated escrow/title status is only an attributed assertion from an authorized external source.

H-27  Escrow liabilities and provider funds remain distinct from platform revenue.

H-28  Every posted journal balances per currency in exact minor units and is immutable.

H-29  Budget reservations are atomic across concurrent actions and remain held during unknown effect.

H-30  Timeout and ambiguous not-found do not prove external failure or authorize blind retry.

H-31  Webhook/poll races create at most one provider effect, entitlement, settlement and active journal batch.

H-32  Transfer advances relevant epochs and invalidates prior sessions, grants, caches, credentials and scheduled effects.

H-33  Signatures prove provenance/integrity of bytes under a trust decision, not physical or legal truth.

H-34  Key compromise appends status and re-evaluation; it never rewrites signed history.

H-35  Corrections, revocations, refunds, reversals and invalidations append.

H-36  Canonical RecordCore excludes tenant placement, stream order, transaction time and transport retry state.

H-37  Canonical and projected resources expose distinct digests/ETags and authorization semantics.

H-38  Telemetry values are inseparable from channel, unit, frame, clock, calibration, configuration and quality.

H-39  Capability outcomes distinguish available, unavailable, unknown and compiler error.

H-40  A physical-control command requires a current function lease, authority epoch, frame, envelope and safety decision.

H-41  Last-write-wins is forbidden for evidence, authority, configuration, auction, budget and accounting conflicts.

H-42  Every projection can be destroyed and rebuilt from ledger, artifacts, registry locks and deterministic code.

H-43  Every release proves canonical vectors, migration safety, replay and tenant non-interference before promotion.

H-44  Availability degradation never spends correctness, privacy, accounting or physical-safety invariants.

### H2. Cross-plane action transition matrix

| Current state | Allowed next states | Mandatory evidence / guard |
| --- | --- | --- |
| PROPOSED | POLICY_EVALUATING \| EXPIRED | typed proposal digest and accountable actor/workload |
| POLICY_EVALUATING | DENIED \| AWAITING_CONFIRMATION \| RESERVING | decision receipt at current epochs/checkpoints |
| AWAITING_CONFIRMATION | CONFIRMED \| REJECTED \| EXPIRED | exact challenge/terms digest; required authentication; one-time use |
| CONFIRMED | RESERVING \| EXPIRED | unchanged proposal and fresh decision inputs |
| RESERVING | READY_TO_DISPATCH \| RESERVATION_FAILED | atomic mandate/rate/inventory reservation |
| READY_TO_DISPATCH | DISPATCHING \| DENIED \| EXPIRED | immediate policy recheck and unconsumed nonce |
| DISPATCHING | EFFECT_CONFIRMED \| DEFINITIVE_REJECTION \| UNKNOWN_EFFECT | provider request digest and transport evidence |
| UNKNOWN_EFFECT | RECONCILING | reservation held; automatic redispatch forbidden |
| RECONCILING | EFFECT_CONFIRMED \| PROVEN_NOT_EFFECTED \| OPERATOR_REQUIRED | authenticated correlated provider evidence |
| EFFECT_CONFIRMED | SETTLING \| COMPENSATING | provider effect receipt; exactly-once economic event |
| SETTLING | SETTLED \| COMPENSATING \| OPERATOR_REQUIRED | milestone and journal receipts |
| PROVEN_NOT_EFFECTED | READY_TO_DISPATCH \| CLOSED | new current authorization/confirmation and connector retry permission |
| COMPENSATING | COMPENSATED \| OPERATOR_REQUIRED | separate authorized compensating action and accounting |
| SETTLED \| DENIED \| REJECTED \| EXPIRED \| COMPENSATED | terminal | later change is a new action, never state rewrite |

### H3. Failure disposition registry

| Disposition | Storage behavior | Permitted downstream behavior |
| --- | --- | --- |
| REJECT | no semantic admission; bounded safe failure receipt | none; caller may correct and use new request/key as defined |
| QUARANTINE | retain isolated raw bytes and security metadata | forensic/review only; no normal projection or derivation |
| ACCEPT_PENDING | admit interpretable bytes with unresolved non-authorizing refs | no capability, market, safety or factual promotion |
| ACCEPT_DEGRADED | admit plus exact quality/prohibition flags | only consumers explicitly accepting every limitation |
| ACCEPT_CONFLICTED | retain incompatible evidence without merge | conflict-aware views; no authority from conflict |
| DUPLICATE | return original receipt; no new record/event | continue from original checkpoint |
| EQUIVOCATION | quarantine competing bytes and append incident | no winner by arrival order |
| UNKNOWN | record absent/uncertain required fact | propagate unknown; cannot authorize consequential action |
| ERROR | compiler/runtime failed to produce a semantic answer | retry/repair; never coerce to false/available |
| ABORT_TO_SAFE_STATE | append command/runtime failure and fallback evidence | only asset-specific local fallback |
| FAULT_LATCHED | persist until authorized recovery clearance | no direct re-arm/active transition |
| INVALIDATE_DERIVATIONS | append invalidation and dependency traversal | recompute descendants; preserve source/history |
| OPERATOR_REQUIRED | preserve reservations/exposure and full evidence | no automatic retry, settlement or concealment |

# Appendix I. One hundred thirty-two additional implementation conformance fixtures

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.appendix.i · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:317b6a663ad39ee986e2232275d9027f545b2d4648ff99d3d8ae2933f532557a

Together with Appendix E, this raises the release-gate corpus to 256 cases. Each case requires canonical machine-readable inputs, expected disposition/code, before/after state for transactional cases and replay evidence. A passing UI screenshot is not a conformance result.

### I1. Quantities, frames, and numerical representation

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-125 | Convert exactly 1 lbf·ft to 1.3558179483314004 N·m | Accept the exact declared conversion; retain source representation, unit definitions and transform receipt. |
| T-126 | Add 20 °C and 10 °C as two absolute temperatures | Reject affine-unit misuse; only an absolute temperature plus a temperature interval is dimensionally legal. |
| T-127 | Receive a NaN bit pattern from a normalized sensor channel | Preserve exact raw IEEE bits with invalid quality; never emit a factual QuantityValue. |
| T-128 | Supply a covariance matrix with a materially negative eigenvalue | Reject the uncertainty object as not positive semidefinite under the locked tolerance. |
| T-129 | Supply quaternions q and -q for the same pose | Treat rotations as equivalent and serialize the profile's deterministic canonical sign. |
| T-130 | Close a transform loop with 0.5 m residual under a 1 mm tolerance | Mark the frame graph inconsistent and prohibit fused pose; retain residual as calibration evidence. |

### I2. Time, telemetry, and segment integrity

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-131 | A 32-bit microsecond producer tick wraps once under a declared wrap model | Reconstruct monotonic device time only inside the same bootId and increase mapped-time uncertainty. |
| T-132 | Two observations' time intervals overlap after uncertainty expansion | Report physical order unknown; do not break the tie with database arrival time. |
| T-133 | Channel datatype changes halfway through a telemetry segment | Reject or split exactly at the change; one manifest cannot silently reinterpret rows. |
| T-134 | Plaintext digest matches but encoded ciphertext digest fails | Quarantine storage/transmission corruption even though semantic plaintext identity is known. |
| T-135 | Compressed telemetry exceeds the 100:1 expansion limit | Terminate bounded decoding before full allocation and reject/quarantine by policy. |
| T-136 | A late segment fills a previously declared gap | Append completeness correction and invalidate/recompute every affected metric; do not edit the old assessment. |

### I3. Configuration and capability computation

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-137 | Fan bicycle has wheel support and an air-thrust fan | Realize locomotion without requiring driven wheels; preserve support/propulsion separation. |
| T-138 | Blimp has adequate buoyancy but a failed propulsion battery | Support remains available; controlled translation is unavailable; payload action may be separately evaluated. |
| T-139 | Propeller is installed but has no continuous energy path | Configuration may be structurally valid while propulsion capability evaluates false with a broken-path proof. |
| T-140 | Voltage ranges intersect but connector polarity conflicts | Reject the realized electrical connection despite numeric range intersection. |
| T-141 | Resource graph contains an algebraic loop without a registered solver | Return compiler ERROR with loop proof; never coerce to unavailable or available. |
| T-142 | A critical effectivity input is not known at the evaluation checkpoint | Return UNKNOWN and prohibit operation authorization dependent on that capability. |

### I4. Control authority, arbitration, and safety

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-143 | Command arrives under the previous authority epoch | Reject before actuator dispatch and append stale-authority disposition. |
| T-144 | Equal-priority controllers issue incompatible steering commands | Declare conflict and invoke the registered fallback; do not average without a blend contract. |
| T-145 | Handover commits but the new controller never produces acknowledged command | Trigger the handover deadline fallback and retain both controller/barrier receipts. |
| T-146 | Remote closed-loop link is lost | Execute the local asset/domain-specific minimum-risk response within the declared deadline. |
| T-147 | Emergency stop is followed by an ordinary arm command | Reject until authorized recovery check clears the latched state. |
| T-148 | Position command has correct units but the wrong coordinate frame | Reject; never infer or silently transform the command frame. |

### I5. Models, tests, dyno, and maintenance

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-149 | Estimator inputs leave the model's validation domain | Mark output OUT_OF_DOMAIN and prohibit control/safety use; retain as qualified analysis if policy permits. |
| T-150 | Wheel-dyno and crank-bench runs show equal headline power | Classify as different measurement boundaries and not directly comparable. |
| T-151 | Static-thrust test shows thrust but zero useful translational power | Accept without invented propulsive efficiency or division by zero. |
| T-152 | Normalized innovation remains above threshold for the required window | Mark the digital twin DIVERGED and invoke its reset/fallback policy. |
| T-153 | RUL model receives a duty cycle outside validated population | Return unknown distribution/application status instead of extrapolated remaining life. |
| T-154 | A calibration is retracted after metric publication | Append invalidation, traverse dependency graph, recompute and publish correction lineage. |

### I6. Cross-domain physical semantics

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-155 | A 1:8 RC model is geometrically similar but Reynolds number differs | Reject full dynamic-similarity claim; report geometric and aerodynamic fidelity separately. |
| T-156 | Amphibious craft crosses shore with wheel and marine constraints simultaneously active | Require an explicit hybrid transition mode with guards, hazards and reset map. |
| T-157 | Underwater glider advances by buoyancy cycling without propeller | Realize locomotion through variable buoyancy plus hydrodynamic lift. |
| T-158 | Spacecraft vectors share numbers but differ in frame and epoch | Prohibit comparison until exact transform/propagation and uncertainty are supplied. |
| T-159 | Tether solver produces compressive negative tension | Enter slack-tether mode; clamping the force while retaining taut equations is forbidden. |
| T-160 | Rail consist loses one brake controller | Recompute consist and route-specific braking envelope rather than marking the train generically broken. |

### I7. Principal identity and credentials

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-161 | User attempts authentication with KUN's VIN | Reject and create no AuthenticatedContext. |
| T-162 | Stolen access token is presented without its DPoP/mTLS key | Reject proof-of-possession and record safe authentication failure. |
| T-163 | Valid signature uses a key after compromise-effective time | Reject current authority and mark affected historical evidence for trust re-evaluation. |
| T-164 | Untrusted external credential claims ownership | Retain as issuer assertion; grant no internal authority. |
| T-165 | Workload presents a token for a human-facing audience | Reject audience/actor mismatch. |
| T-166 | Old token is used after principal epoch advancement | Reject stale epoch even if token signature and expiry are otherwise valid. |
| T-167 | One recovery delegate attempts a two-member R4 recovery | Reject until quorum and required authenticators are satisfied. |
| T-168 | Authentication assurance drops between proposal and dispatch | Reevaluate and deny or issue a new challenge; old positive decision is unusable. |

### I8. Grants, relationships, and policy

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-169 | Sale grant uses an unbounded resource wildcard | Reject the R4 grant as non-attenuated/non-specific. |
| T-170 | Ownership exists but may_list_for_sale is absent | Deny listing; never infer sale authority from title interest. |
| T-171 | Required relationship expires one second before dispatch | Deny after immediate valid-time reevaluation. |
| T-172 | One policy permits while another explicitly denies | Deny and name the controlling prohibition without disclosing private policy data. |
| T-173 | Jurisdiction is indeterminate for a binding sale | Return indeterminate and enforce deny. |
| T-174 | Policy engine is unavailable for an R3 action | Fail closed; do not reuse an unbounded stale positive cache. |
| T-175 | Cached permit is presented after grant revocation | Reject by epoch/checkpoint mismatch. |
| T-176 | Required audit duty cannot be durably committed | Do not dispatch the external effect. |

### I9. Consent, privacy, rights, and non-interference

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-177 | Maintenance-purpose consent is reused for advertising | Deny purpose mismatch. |
| T-178 | Consent is withdrawn while campaign content is scheduled | Freeze publication/campaign, invalidate caches and start lineage remediation. |
| T-179 | Data under legal hold is requested for unrelated marketing | Retain under hold but deny the use. |
| T-180 | A legal hold selects every tenant record without scoped authority | Reject or require exceptional separately governed approval. |
| T-181 | Minor-associated media lacks required consent/guardian basis | Deny publication and retain only under applicable evidence/retention policy. |
| T-182 | Withdrawn data contributed to a derived model | Block new dependent use and open lineage-based remediation; do not erase audit history. |
| T-183 | Disclosure record omits recipient or purpose | Reject it before any bytes leave the boundary. |
| T-184 | Adding a private vehicle changes a public result count | Fail the public projection non-interference test. |

### I10. Agent, content, voice, and connector isolation

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-185 | Service note says to ignore policy and transfer money | Store as inert evidence; create no tool call, memory promotion or authority change. |
| T-186 | Retrieved page requests fetching an arbitrary URL | Block direct fetch; only an independently authorized allowlisted fetch proposal may proceed. |
| T-187 | Model output requests a generic HTTP tool | Reject unknown tool/schema at the post-model enforcement point. |
| T-188 | Post states unsupported horsepower as fact | Block publication or require an exact evidence-backed qualifier. |
| T-189 | KUN says it felt proud | Permit only as disclosed persona/creative expression, never observed affect. |
| T-190 | Voice right expires before scheduled publication | Freeze output and require renewed rights/approval. |
| T-191 | Platform transcoding strips embedded media provenance | Preserve visible disclosure and sidecar provenance/lineage or withhold publication. |
| T-192 | Model provider retention terms conflict with source policy | Route to an approved provider/runtime or deny generation. |

### I11. Spotting, advertising, and recruitment abuse

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-193 | Spotting image reveals a home driveway | Keep private or deny; home/storage inference is not publicly projected. |
| T-194 | Visible map is coarse but image EXIF contains precise coordinates | Strip/transform EXIF before any publication. |
| T-195 | Repeated coarse sightings permit route triangulation | Suppress or increase time delay/spatial coarsening using aggregate abuse analysis. |
| T-196 | Reporter probes whether vehicle is on suppression list | Return the same generic non-revealing response as other unresolved cases. |
| T-197 | Plate text exactly matches one profile | Create a candidate with calibrated evidence; do not merge identity or reveal private profile. |
| T-198 | Ad model infers owner income or health from vehicle data | Deny and record a policy incident. |
| T-199 | Defect telemetry is offered to insurer without exact authority | Deny disclosure and targeting. |
| T-200 | Follower popularity is used to reject an applicant | Prohibit the feature and invalidate the recruitment decision process. |

### I12. Auctions and settlement

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-201 | One bid digit changes after exact confirmation | Reject proposal/terms digest mismatch. |
| T-202 | Same bid key and same bytes are retried | Return the original admission receipt; create no duplicate bid. |
| T-203 | Same bid key arrives with different bytes | Quarantine/report equivocation and admit at most the original. |
| T-204 | Bid arrives after close with earlier client timestamp | Reject; trusted receive time controls eligibility. |
| T-205 | Equal bids arrive sequentially | Apply the locked tie rule using admission sequence or other predeclared deterministic input. |
| T-206 | Seller or prohibited related party bids | Exclude under locked eligibility policy and retain evidence. |
| T-207 | Seller changes reserve after auction opens | Reject the mutation; cancel/relist only through explicit allowed process. |
| T-208 | Bid lands exactly at anti-sniping lower boundary | Apply the locked inclusive lower/strict close-boundary expression exactly. |
| T-209 | Close and bid admission race | Serializable ordering permits exactly one outcome around the close fence. |
| T-210 | Payment succeeds but title review fails | Do not transfer; suspend and compensate/refund/dispute per settlement profile. |
| T-211 | Escrow status comes from an unregistered provider | Do not mark funds in escrow; retain as untrusted assertion. |
| T-212 | Later higher offer arrives after close | Winner and close price remain unchanged. |

### I13. Accounting, mandates, and unknown effects

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-213 | Journal differs by one minor currency unit | Reject posting; no rounding tolerance. |
| T-214 | EUR and CZK balance only when combined | Reject; each currency group must balance independently. |
| T-215 | Refund attempts to edit original capture entry | Reject mutation; append refund/reversal batch. |
| T-216 | Two concurrent EUR 60 actions use a EUR 100 mandate | Atomic reservation permits at most one. |
| T-217 | Payment request times out after possible dispatch | Enter UNKNOWN_EFFECT and retain budget reservation. |
| T-218 | Unsigned webhook reports payment success | Quarantine; do not settle, entitle or post journal. |
| T-219 | Provider poll proves success after timeout | Settle exactly once and consume the existing reservation. |
| T-220 | Non-idempotent provider returns ambiguous not-found | Require operator resolution and prohibit automatic retry. |

### I14. Transfer, compromise, and audit

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-221 | Title transfers while persona rights remain with seller | Freeze, fork, retire or explicitly relicense persona; no silent continuity. |
| T-222 | Old provider token remains active after transfer | Fail succession conformance; revoke/rotate and advance relevant epoch. |
| T-223 | Key compromise is discovered retroactively | Append compromise interval and re-evaluate dependent proofs without rewriting records. |
| T-224 | Audit inclusion proof disagrees with signed checkpoint | Raise tamper incident and reject the evidence bundle. |

### I15. Wire grammar and digest separation

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-225 | New entity root is minted as UUIDv7 | Reject profile mismatch; durable roots use opaque UUIDv4 while events/records use UUIDv7. |
| T-226 | Record UUID is uppercase or nil | Reject lexical form before digesting. |
| T-227 | Open interval encodes end:null | Reject; omit end for open interval. |
| T-228 | Parser receives duplicate profile members | Reject before materializing object. |
| T-229 | Proof is added to an existing RecordCore | Record digest remains unchanged; ProofRecord/proof-set digest changes. |
| T-230 | Same RecordCore is admitted into another tenant | Portable record digest remains equal; admission receipt digest changes. |
| T-231 | Projection changes audience/redaction only | Projection digest/ETag changes; record and receipt digests remain stable. |
| T-232 | Transport retry count is inserted into canonical EventData | Reject event schema; retry metadata stays outside canonical event. |

### I16. Ledger, registry, migration, and supply chain

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-233 | Two first-time requests race on an absent idempotency row | INSERT ON CONFLICT then lock produces one binding and deterministic duplicate/equivocation handling. |
| T-234 | Append transaction aborts before ShardHead commit | No commitSequence is consumed; stream and shard heads remain unchanged. |
| T-235 | Writer presents a stale writer epoch | Reject even when expected sequence is correct. |
| T-236 | Outbox row publishes twice after crash | Consumer applies once by eventId and atomically stored checkpoint. |
| T-237 | Registry import references mutable latest schema | Reject; require immutable ID/version/digest lock. |
| T-238 | Migration changes a historical RecordCore in place | Reject; emit new record plus MigrationReceipt and lineage. |
| T-239 | Revoked pack is required to verify old evidence | Allow verification under incident policy; prohibit new authoring/compilation. |
| T-240 | Deployment artifact digest differs from signed provenance | Stop promotion/activation and record supply-chain incident. |

### I17. HTTP, query, events, SDK, and federation

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-241 | Client retries timeout with a new idempotency key | SDK conformance fails; query old key/result before any new intended effect. |
| T-242 | Canonical GET returns a projection ETag | Fail API contract; canonical ETag must bind record digest. |
| T-243 | Cursor is replayed under another principal or policy | Reject signature/binding and start a new query. |
| T-244 | Query requests arbitrary SQL or unbounded recursive relationship path | Reject typed-query validation. |
| T-245 | Consumer commits view state but not event checkpoint atomically | Fail event conformance; crash test demonstrates duplicate/skip risk. |
| T-246 | SDK maps unknown enum to default AVAILABLE | Reject generated SDK; unknown value remains typed unknown/unsupported. |
| T-247 | Offline device uploads same sample identity with different bytes | Quarantine equivocation; do not use last-write-wins. |
| T-248 | Federated Follow is treated as private dossier access | Deny; social relationship carries no data/action grant. |

### I18. Operations, recovery, scale, and release

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-249 | Ledger overload returns success after only queueing bytes | Fail correctness; success requires durable committed receipt. |
| T-250 | Public projection cache omits checkpoint and policy digest | Reject cache entry/response as non-reproducible. |
| T-251 | Redis loss removes auction leader or mandate balance | Architecture conformance fails; disposable cache cannot be authoritative. |
| T-252 | Backup restores database but referenced object digest is missing | Recovery remains failed; do not issue RecoveryAttestation. |
| T-253 | Projection rebuild from same checkpoint produces different digest | Stop release/recovery and investigate code, registry or nondeterminism. |
| T-254 | Policy cache remains positive after revocation propagation delay | Dispatch-time epoch check denies despite cache. |
| T-255 | Canary changes canonical bytes across language implementations | Stop rollout; canonical corpus requires byte equality. |
| T-256 | Error budget is exhausted while invariant tests stay green | Freeze risky availability changes and prioritize reliability; do not weaken invariants. |

# Appendix J. Cross-domain reference transactions and proof obligations

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.appendix.j · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:8b16054d0b8f25f0bd70846be44af9fcf405c1143de1718a014270b6f34b0e07

The universal substrate is proved by applying the same identity, evidence, graph, time, authority, lifecycle and projection laws to physically different machines. Domain packs add vocabulary, equations and policy; they do not replace the kernel.

### J1. KUN ‘Prague Workhorse’: evidence-to-story-to-value transaction

| Phase | Canonical records | Technical proof | Product expression |
| --- | --- | --- | --- |
| care intake | CareActivity + before media + capture/custody receipts | surface/process/product/equipment/environment; condition observations remain distinct | private raw gallery; public wash story after rights/privacy projection |
| connected drive | CaptureSession + channel/clock/config locks + segments | raw CAN/GNSS/camera values; boot/sample identities; gap and quality assessment | owner telemetry; delayed/coarsened mission card |
| diagnosis | DiagnosticAssessment + fault alternatives + evidence | suspected/isolated/confirmed states; no unsupported certainty | maintenance recommendation with scope and uncertainty |
| work + parts | WorkOrder + executions + consumptions + calibration | actual part instances/lots, labor, torque/procedure, findings and deviations | rebuildable maintenance record and service-cost view |
| modification | ChangeRequest + assessment + configuration diff + release | ports, energy/control paths, software/calibration and affected capabilities recompiled | before/after build story and verified-current scope |
| dyno/test | TestPlan + setup snapshot + raw artifact + result | measurement boundary, environment, correction, uncertainty and comparability signature | qualified performance chart; no crank/wheel conflation |
| vehicle post | AgentContextManifest + draft + atomic claims + approval | observed/asserted/derived/creative lanes and exact evidence checkpoint | KUN speaks vividly while factual claims remain traceable |
| sponsorship | CampaignPolicy + RightsGrant + PublicationReceipt + journals | sponsor terms, permitted vehicle facts, disclosure, consideration and beneficiary | clearly labeled partner content and balanced earnings |
| listing + bid | Listing + AuctionRuleSet + BidAdmission receipts | seller authority, dossier/config digest, terms, trusted bid ordering and reserve commitment | live asking/leading-bid surface with precise value nouns |
| close + transfer | CloseReceipt + SettlementSaga + TransferPlan | winner, money, inspection, custody, external title assertion and persona disposition stay independent | explicit new stewardship/fork/retirement and revoked old access |

```text
Value is an output of accumulated trust—not an editable score
KUN's public value narrative can combine provenance, condition, maintenance completeness, current configuration, test comparability, cultural reach, event history and eligible market evidence. The source records remain visible by category and confidence; social engagement cannot overwrite defects, title conflicts or auction outcomes.
```

### J2. 1/8 electric RC buggy

| Facet | Exact representation | Domain-specific differentiator |
| --- | --- | --- |
| identity | physical model asset + scale/represents relationship + chassis/electronics/pack instances | never merged with full-size represented vehicle |
| support | four tire contact patches, suspension and ground frame | setup-sensitive ride height, camber, toe, droop and tire compound |
| propulsion | battery → ESC → motor → pinion/spur/differential → driven wheels | pack chemistry/C-rating, gearing, motor timing, thermal and current limits |
| control | human radio steering/throttle; optional gyro by function; failsafe | transmitter/receiver binding, link, latency and race-class restrictions |
| operation | track, heat, driver, marshal, transponder, lap timing and exact setup snapshot | competition rule pack and class eligibility attach to operation |
| lifecycle | battery cycles, tire sets, crashes, rebuilds, bearings/gears/shocks and setup deltas | small replaceable parts still retain lot/instance provenance where valuable |
| physics | geometric/inertial/aero/tire/control similarity dimensions | 1:8 label does not imply Reynolds, Froude or full dynamic similarity |

### J3. Remotely operated blimp with camera and gripper

```text
Support, propulsion, tether, utility and control remain separate
Configuration A — tethered display:
  helium envelope supplies aerostatic support
  tether supplies constraint and may carry power/data
  electric propellers supply air-reaction translation/yaw
  camera observes; gripper manipulates under separate utility authority

Transition guard to Configuration B — free flight:
  net lift margin inside bound
  weather/airspace/energy/link/envelope-health predicates TRUE
  tether release authorized by its own hazardous-function lease
  free-flight controller READY; authority epoch barrier committed

Lost link in free flight invokes local blimp fallback: stabilize/maintain altitude,
respect geofence and energy margin, then recover/land at declared site. A generic
"stop" command is physically incomplete.
```

- Envelope identity/configuration tracks gas composition, cells/ballonets, pressure, volume, temperature, leakage, valves, patches and life limits.

- Net lift is a computed interval over air/gas density, envelope/structure/payload weight and uncertainty—not a boolean lighterThanAir field.

- Camera media binds capture configuration, pose/frame/clock, rights and privacy; gripper task evidence does not imply flight-control authority.

- Famous persona and event followers do not expand airspace, weather, payload, tether-release or operator authority.

### J4. Fan-propelled bicycle versus two propeller boats

| Machine | Support path | Propulsion/reaction path | Differentiating safety/test facts |
| --- | --- | --- | --- |
| fan bicycle | wheels/tires support on ground; front geometry steers | battery/engine → fan/air propeller → thrust against air | exposed rotor/guard, air thrust, wheel rolling losses; driven-wheel assumptions invalid |
| airboat | displacement/planing hull supports on water | engine → above-water air propeller → thrust against air | guard/noise/airflow, rudder/slip, hull/water state; propeller not submerged |
| conventional propeller boat | displacement/planing/hydrofoil hull supports on/in water | engine/motor → shaft/pod → propeller → thrust against water | cavitation/ventilation, shaft seal, fouling and advance ratio; airboat equations not substituted |

All three may be called propeller-driven, but propeller location, reaction medium, support medium, transmission, steering, hazards, maintenance and performance model differ. These facts are orthogonal axes; the preferred community label is a recipe result.

### J5. Underwater glider without propulsive propeller

```text
Variable buoyancy plus hydrodynamic lift is a complete propulsion mechanism
Cycle mode DIVE:
  reduce displaced volume / adjust ballast -> negative buoyancy
  pitch mechanism establishes descent attitude
  wings convert vertical motion into forward hydrodynamic lift

Cycle mode CLIMB:
  increase displaced volume / adjust ballast -> positive buoyancy
  shift mass/trim -> ascent attitude
  wings again create forward component

State and evidence bind:
  pressure/depth-positive frame, water density/current, hull volume,
  pump/ballast energy, pitch/roll, leak/pressure-envelope state,
  acoustic/satellite communication windows and surfacing fixes.

Locomotion capability is realized even when propeller count == 0.
Unknown density/current or pressure-envelope health may make mission feasibility
UNKNOWN although the generic motion recipe still matches.
```

### J6. Transforming road eVTOL

| Mode | Active physical graph | Required transition evidence |
| --- | --- | --- |
| road | wheel support/traction, road steering/braking, folded flight surfaces, road software/calibration | flight propulsion inhibited; road configuration and regulatory/operation assertions |
| deploying | actuators move wings/rotors; both road and flight clearance/energy constraints may apply | interlocks, exclusion zone, latch/position sensors, wind and fault checks |
| vertical flight | rotor lift/thrust, attitude control, airborne navigation and energy/thermal model | flight control lease, mass/CG, weather/airspace, rotor and battery health |
| wing-borne | aerodynamic wing lift plus propulsive thrust; transition controller | airspeed/attitude/altitude envelope and validated transition model |
| landing + stowing | flight then ground support; rotor stop and mechanical stow/latch | touchdown/load evidence, safe rotor state, clearance and configuration verification |

One permanent asset identity spans modes, while every observation, capability, control lease, operation, incident, service task, performance result and registry assertion binds the exact configuration/mode interval. Social popularity, auction price or agent confidence cannot authorize a transition or flight.

### J7. Minimum proof package for a new niche domain

1. Define domain terms as versioned TermRefs with definitions, provenance, owners, synonyms and mapping—not one new universal enum.

1. Show at least one complete support graph, resource/energy graph, propulsion/force path, steering/stopping path and useful-action graph.

1. Define ports, mediums, units, frames, clocks, effectivity, configuration and failure behavior needed for the distinguishing mechanism.

1. Register quantitative model families with equations, constraints, valid domains, solvers, initialization and validation evidence; do not force one physics model across all machines.

1. Define operational modes, transition guards/reset maps, control functions, local fallbacks, hazards and release evidence.

1. Define lifecycle activities, consumables, wear/fault families, inspection/maintenance and identity-continuity decisions relevant to the community.

1. Define privacy, rights, registry, competition, marketplace and cultural mappings as adapters; none rewrites kernel identity or physics.

1. Ship positive, negative, unknown, conflict, malicious-input, numerical-edge and cross-domain conformance fixtures plus one full ledger replay.

# 45. Institutional identity, functional roles, authority, and external-source adapters

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.45 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:5cb4bb142d7046cc9b080643af769d2669e950d414a68b77e6f3714b2262704e

RTracer must interoperate with registries, insurers, assessors, repairers, event operators, payment providers, marketplaces, tax services, safety bodies, clubs, schools, employers, and government authorities. An institution profile identifies an actor; it does not prove that the actor is competent, current, applicable, or authorized for the requested act. Every consequential institutional result remains an attributed, time-bound assertion evaluated under a pinned policy.

### 45.1 Institution identity is not authority

An InstitutionProfile binds one platform principal to declared names, legal-identity assertions, service endpoints, jurisdiction claims, qualification evidence, and status. The profile MUST NOT grant a functional role by itself. A brand page, verified domain, registry number, payment account, or prior transaction MUST NOT be treated as current authority.

| Layer | Answers | Does not answer |
| --- | --- | --- |
| InstitutionProfile | Which principal claims or proves which institutional identity? | Whether it may make this decision now |
| InstitutionalRoleAssignment | Which issuer attributes which functional role, scope, jurisdiction, and interval? | Whether the caller authenticated or received a platform grant |
| CapabilityGrant | Which authenticated principal may perform which platform action over which resources? | Whether an external legal or professional conclusion is true |
| ExternalAuthorityAssertion | What did a named external source assert, when, and from which native record? | Universal truth outside the issuer and policy scope |
| CaseDecision | What scoped outcome did an accountable decider select from a pinned evidence set? | Erasure of competing evidence or appeal rights |

### 45.2 Functional-role assignments and qualification assertions

Functional roles are vocabulary terms such as vehicle_registry_source, title_reviewer, insurer, loss_assessor, repairer, safety_inspector, moderation_reviewer, appeal_reviewer, auction_operator, market_integrity_reviewer, incident_commander, tax_determination_provider, and management_team_member. A role assignment records issuer, authority basis, permitted action families, subject selectors, domain and jurisdiction scopes, restrictions, valid interval, and verification state.

A current role assignment is necessary but insufficient for a platform effect. The runtime MUST also authenticate the acting principal, resolve a current attenuated CapabilityGrant, apply separation-of-duty rules, and evaluate action-specific policy at dispatch. Role assignments and grants expire, suspend, dispute, and revoke independently.

### 45.3 External query and assertion receipts

Every external lookup produces an ExternalAuthorityQueryReceipt even when the result is NO_MATCH, AMBIGUOUS, UNAVAILABLE, or ERROR. The receipt binds the source institution, endpoint profile, query-selector digest, requested assertion kinds, request and response times, raw response artifact digest, source proofs, and freshness policy.

Native response bytes are retained as evidence when policy permits. Normalized values are separate versioned derivations carrying the vocabulary, transformation code digest, input artifact digest, and limitations. An unavailable response or NO_MATCH MUST NOT be projected as absence of title interest, lien, restriction, insurance, recall, theft report, tax duty, or other real-world fact.

### 45.4 Authority applicability, freshness, and conflicts

Authority evaluation is a function of issuer, functional role, subject, asset/configuration, action, jurisdiction, effective interval, fetch time, source freshness policy, proof status, conflict set, and requested consequence. A cryptographically valid but stale assertion may remain useful historical evidence while being ineligible for a transfer or safety decision.

| Input condition | Required projection |
| --- | --- |
| current, applicable, independently verified | eligible input; never automatic truth |
| stale | preserved with stale status; refresh or decide under explicit exception |
| source unavailable | unavailable; no negative inference |
| two applicable sources conflict | conflicted; retain both and open review where required |
| issuer role expired or revoked | provenance retained; ineligible for new high-impact decisions |
| jurisdiction or subject scope unknown | indeterminate; fail closed for R3/R4 effects |

### 45.5 Institutional service endpoints and trust profiles

An endpoint profile pins transport, authentication, response schemas, native identifiers, proof verification, rate limits, retention, privacy, incident contacts, and query semantics. Trust profiles state which assertion kinds the platform may accept from which institutional roles, their maximum age, corroboration requirements, and permitted consequences. Endpoint availability never changes the semantics of a stored assertion.

# 46. Common casework, decision, notice, appeal, and remedy runtime

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.46 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:2a351e5eb04e7feb0320d55918ad160b1de5667c4d7a6cf6aef9e5694060b6d4

Title conflicts, insurance claims, moderation, market integrity, incidents, privacy complaints, safety reviews, and transfer disputes share one append-only case kernel. Domain packs add local terminology and deadlines, but they MUST NOT replace the common evidence, authority, notice, appeal, remedy, and accountability boundaries.

### 46.1 Append-only case kernel

A CaseFile names the case kind, subjects, participants, initiating records, policy and jurisdiction locks, confidentiality policy, assigned team, accountable principal, reviewer requirements, priority, target dates, and initial state. Each CaseTransition supplies the expected case sequence, from-state, to-state, trigger, actor, authority assignment, evidence or decision references, reason codes, and occurrence time.

Case state is a projection over transitions. Evidence, decisions, notices, appeals, and remedies append. Closing, reopening, correcting, vacating, or remanding a case never deletes the earlier state.

### 46.2 Parties, representatives, and confidentiality

Case participants have explicit roles such as reporter, subject, claimant, respondent, victim, witness, representative, reviewer, decider, regulator, or observer. Representation authority is attributed and time-bound. Confidentiality is field- and artifact-specific; membership in a case does not imply access to every submission, reporter identity, protected signal, minor-associated record, or privileged material.

### 46.3 Evidence submission and disclosure

A CaseEvidenceSubmission binds submitter, represented party, artifacts, propositions, custody references, disclosure class, restrictions, submission time, admission disposition, and challenges. The system distinguishes submitted, admitted, excluded, disputed, unavailable, and withdrawn-for-use evidence without erasing bytes held for audit or legal retention.

Disclosure creates a receipt naming recipient, purpose, exact fields/artifacts, policy decision, redactions, duties, and expiry. Evidence made available for one case purpose MUST NOT silently enter advertising, training, public profiles, recruitment, or vehicle-agent context.

### 46.4 Decision authority and reasoned outcomes

A CaseDecision binds decider, current authority assignment, conflict declarations, candidate outcomes, selected outcome, policy digest, evidence-set digest, findings, reason codes, exact scope, effective time, review time, notice duties, and appeal policy. A high-impact decision MUST have one named accountable human principal even when models triage, summarize, or recommend.

Automated output is evidence or a recommendation unless a domain pack explicitly authorizes an automated low-impact decision. Scores MUST NOT directly impose permanent moderation, title clearance, insurance denial, auction cancellation, participant restriction, or physical-control authority.

### 46.5 Notice delivery and deadlines

A CaseNotice binds the exact decision or event, recipient, minimized content artifact, disclosed reason codes, channel, dispatch time, delivery disposition, provider receipts, and response deadline. Delivery status is not inferred from a queued message. Protected reporters, minors, victims, integrity signals, security controls, and private evidence are redacted independently from the existence of the case.

### 46.6 Appeals, review independence, and stays

A CaseAppeal references the challenged decision; it never edits it. It records appellant, representative, grounds, evidence, requested outcome, filing time, timeliness decision, reviewer requirements, and state. The selected policy pack declares whether review is de novo or limited, the independence rule, deadlines, available remedies, and whether filing automatically stays the effect.

Review may affirm, modify, vacate, or remand through a new decision. A modified outcome appends new effective scope and transition records while preserving what users could have known before review.

### 46.7 Remedies, enforcement, and reopening

A CaseRemedy names remedy kind, targets, required and prohibited actions, effective interval, responsible principal, verification requirements, completion evidence, and status. Restitution, refund, access restoration, content relabeling, profile unfreezing, bid reinstatement, title re-review, repair correction, and data-use remediation remain distinct effects with separate authorization and reconciliation.

Reopening a final case requires a separately authorized decision and reason such as new evidence, procedural defect, fraud, external correction, or failed remedy. It does not move the historical case backward.

# 47. Registry, title interests, liens, restrictions, and transfer clearance

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.47 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:50ffa76fc881c14b6a4b063767e28be067156c1f4ec860e67adde9f4971e02b5

RTracer can aggregate official and private registry evidence without pretending to become every registry. Vehicle identity, legal-account identity, title interest, beneficial interest, lien or encumbrance, custody, possession, profile administration, seller authority, restriction, and platform transfer clearance are separate records.

### 47.1 Registry identifiers and issuer assertions

Registry identifiers are IdentifierAssertions scoped to issuer namespace, native system, normalization version, subject, jurisdiction, and effective interval. A VIN, registration mark, radio identifier, serial, model number, MAC address, aviation registration, maritime identifier, rail number, club number, or RC transponder can contribute identity evidence but MUST NOT independently prove continuity, ownership, legality, or fitness.

### 47.2 Title-interest assertions

A TitleInterestAssertion names asset, asserted holders, interest class, issuer assertion, native status, effective interval, priority or order where supplied, restrictions, and state. Interest classes are vocabulary terms supplied by jurisdiction packs; the kernel does not collapse them into a universal owner boolean.

### 47.3 Encumbrance and release assertions

An EncumbranceAssertion records interested principals, class, issuer evidence, amount where disclosed, effective interval, native status, and any later release assertion. A release only addresses the encumbrance it identifies. A release predating a newer encumbrance MUST NOT support a no-lien projection.

### 47.4 Theft, recall, salvage, inspection, and transfer restrictions

RegistryRestrictionAssertion represents attributed restrictions on defined action families and, when relevant, exact configurations or operation classes. Theft reports, recalls, salvage status, inspection failures, export/import restrictions, immobilization, safety holds, court orders, sanctions, club bans, or event eligibility decisions remain issuer-specific facts. Public display is separately policy controlled.

### 47.5 Conflict-preserving status assessment

RegistryStatusAssessment is a derived claim over exact query receipts and assertions. It reports matched, missing, stale, disputed, conflicting, and unavailable inputs. The derivation explains source priority policy without discarding lower-priority evidence. New relevant registry evidence invalidates dependent clearance projections.

### 47.6 Transfer-clearance decision

TransferClearanceDecision binds the proposed transfer, required check kinds, query receipts, title interests, encumbrances, restrictions, seller-authority decision, missing/conflicted/stale inputs, conditions, decider, effective time, and expiry. Results are CLEAR_FOR_PLATFORM_STEP, CONDITIONAL, BLOCKED, or INDETERMINATE.

“Clear” means only that the named platform policy permits the named next step until expiry. It is not a universal legal conclusion. Payment, possession, custody, a signed profile, a popular persona, or platform account control MUST NOT satisfy title clearance.

# 48. Insurance, loss assessment, repair authorization, and recovery

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.48 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:56fe684798f33000a1aef40c3a58b0fd9f9a346069c80167b8f3731b5a5934aa

Insurance and repair workflows must join vehicle identity, as-operated configuration, incident evidence, condition, coverage assertions, professional roles, work packages, installed parts, invoices, settlements, and disputes without allowing one record to impersonate another.

### 48.1 Insurance-contract assertions

InsuranceContractAssertion records insurer, native contract reference, insured principals, asset, configuration selector, operation/use and territory scopes, coverage interval, terms artifact, limits and deductibles, source assertion, and native status. An active-looking record is evidence only. Coverage for a specific loss MUST NOT be inferred from premium payment, vehicle telemetry, insurer relationship, or policy status alone.

### 48.2 Loss notice and claim file

LossNotice binds incident, asset, as-operated configuration, notifier, claimants, occurrence interval, private location reference, damage/condition observations, evidence, external submissions, and state. The related insurance CaseFile controls parties, confidentiality, deadlines, authority, evidence, and appeal.

### 48.3 Coverage decisions

CoverageDecision binds claim case, insurer, authority assignment, contract assertions, considered loss scopes, excluded or unresolved scopes, evidence and terms digests, result, conditions, amount caps, reason codes, effective time, and review/appeal policy. Results are ACCEPTED, PARTIAL, DECLINED, PENDING, or INDETERMINATE.

### 48.4 Independent loss assessment

LossAssessment records assessor, qualifications, asset and configuration, inspection procedure, evidence, damage map, causal hypotheses, repairability class, repair and value estimates, uncertainty, limitations, and conflicts. A policy may require the assessor to be independent from the repairer, seller, owner, insurer claims handler, or platform.

### 48.5 Repair estimate, authorization, and amendments

RepairEstimate is a proposal with work package, repairer, configuration, labor, parts, taxes/fees, currency total, assumptions, exclusions, and validity. RepairAuthorization is a separate mandate naming authorizer, authority basis, payer/beneficiaries, approved and excluded scope, caps, part/procedure constraints, deviation policy, interval, and amendment lineage.

Any changed scope, amount, parts class, procedure, or configuration outside the authorization enters AMENDMENT_REQUIRED before further governed work. Emergency physical work may still be recorded truthfully when external circumstances require it; the platform MUST NOT fabricate prior authorization or reimbursement.

### 48.6 Repair execution, inspection, and release

RepairCompletion binds the executed work package, resulting immutable configuration, deviations, installed-part references, measurement and inspection evidence, invoices, release decision, and completion time. Completion, inspection, roadworthiness/fitness release, payment, reimbursement, warranty, and return to service are separate state transitions.

### 48.7 Settlement, recovery interests, and disputes

Payments and journals append independently from coverage appeals, repair disputes, subrogation or recovery interests, salvage disposition, and title review. Provider timeout or ambiguous effect remains UNKNOWN_EFFECT with funds reservation and reconciliation duties. No accounting correction rewrites the incident, assessment, work, or prior decision.

# 49. Moderation, complaints, enforcement, and appeals

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.49 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:853f0f9a76c440b3bdef7b8f1a245e7932e504f350f7da9f2bc32e886a788b92

Vehicle-native social accounts create new moderation surfaces: posts can be generated from telemetry, owners and fans can interact with a vehicle persona, spotting can expose location, sponsorship can influence a voice, and live auctions can turn content into economic action. Moderation therefore needs attributable casework, exact targets, reversible projections, emergency handling, and appeals.

### 49.1 Reports and complaints

ModerationReport records optional reporter, subjects, content or interaction references, category codes, evidence, urgency, safety/privacy flags, requested outcome, and receive time. Anonymous or confidential reporting is supported without converting an allegation into fact.

### 49.2 Triage and evidence preservation

Triage classifies immediate safety, youth, harassment, privacy, fraud, rights, market, security, and physical-risk signals. Original content bytes and relevant projection context are preserved under access-controlled evidence policy before labels or visibility change. Preservation does not authorize continued public display or unrelated reuse.

### 49.3 Moderation decisions

ModerationDecision binds case, decider, reviewer type, policy lock, evidence-set digest, exact target selectors, outcome, reason codes, effective time, expiry, notice, and appeal policy. Outcomes include NO_ACTION, LABEL, VISIBILITY_LIMIT, INTERACTION_LIMIT, CONTENT_RESTRICT, ACCOUNT_RESTRICT, PROFILE_FREEZE, MARKET_HALT, and EXTERNAL_REFERRAL.

A model score, volume of reports, follower count, owner status, or sponsor relationship MUST NOT impose a permanent high-impact action without the review required by policy.

### 49.4 Temporary emergency restrictions

EmergencyRestriction requires exact targets, immediate-risk reasons, issuer, imposition time, automatic expiry, and mandatory review deadline. It MUST expire unless replaced by a reviewed decision. Emergency restriction does not authorize deletion of canonical history or expansion into unrelated assets, principals, tenants, or tools.

### 49.5 Notice, explanation, and appeal

Notices expose enough reason and scope to permit meaningful challenge while protecting reporters, victims, minors, security controls, and integrity signals. Appeals use the common case runtime, pinned review rules, independent assignment where required, and explicit stay behavior.

### 49.6 Restoration, correction, and transparency projections

Restoration appends a new decision and reverses or replaces the projection effect. Corrected labels, restored content, refunded fees, lifted restrictions, and reinstated eligibility have separate receipts. Aggregate transparency reports use privacy-safe counts and MUST NOT leak small cohorts, reporters, protected users, or detector features.

# 50. Youth protection, age assurance, and guardian authority

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.50 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:c2b4ac5b7a053ec06973cb9c2a72075b94af62671276796e7b95cf551c1b768c

The platform may include young builders, RC racers, students, interns, fans, and passengers. Protection is a policy boundary over principals and interactions; a vehicle or robot is never assigned a human age. Exact birth data is highly sensitive and excluded from public profiles, ads, vehicle-agent context, and model training by default.

### 50.1 Data-minimized age assurance

AgeAssuranceAssessment records subject principal, method class, provider assertion where used, coarse result, assurance class, jurisdiction context, policy lock, assessment/expiry times, and a minimized source-data receipt. Results are AGE_UNKNOWN, PROTECTED_AGE_BAND, NON_PROTECTED_AGE_BAND, or INDETERMINATE. The platform stores the minimum needed conclusion rather than a reusable identity dossier.

### 50.2 Guardian-authority assertions

GuardianAuthorityAssertion names protected and guardian principals, issuer or verifier, basis assertions, potentially grantable scopes, jurisdiction, interval, conflicts, and status. It neither authenticates the guardian nor grants an action. Authentication, current authority assertion, and an action-specific CapabilityGrant remain separate.

### 50.3 Child-safe social, location, advertising, and commerce defaults

YouthProtectionProfile selects discoverability, messaging, location precision, behavioral advertising, commerce, publication approval, and model-training rules. Unknown or indeterminate age invokes the selected child-safe default for affected surfaces. Precise live vehicle location, direct messaging from strangers, behavioral targeting, high-risk purchases, and public identity linkage default to deny or coarse projection.

### 50.4 Guardian conflicts, withdrawal, and expiry

Conflicting guardian assertions remain visible to authorized reviewers and may freeze affected grants. Revocation, suspension, dispute, and expiry invalidate dependent dispatch decisions and scheduled actions. A guardian cannot silently transfer authority, access another guardian’s evidence, or override a protected user’s non-waivable rights.

### 50.5 Transition to independent account status

Crossing an age or legal-capacity threshold creates a new protection decision and grant review. It does not publish historical private data, carry forward every guardian permission, or erase prior case history. The newly independent principal receives clear choices about profile continuity, content, followers, data, team roles, and vehicle relationships.

# 51. Delegated management teams and operational accountability

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.51 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:257ae510886917c79ae76554ddfe5ef3c2df9087cd068cc4cc5da3f5fedd778c

A successful vehicle account may eventually involve an owner, steward, mechanic, driver, media lead, sponsor manager, auction operator, accountant, safety reviewer, race engineer, fleet operator, and autonomous agents. The substrate models the team’s charter and assignments without turning a team name into a superuser or treating membership as authority.

### 51.1 Team identity and charter

ManagementTeam names beneficiaries, managed asset/profile selectors, charter, required functional roles, separation rules, escalation policy, and state. A team is an organizational object, not an authenticated principal. Every action is still attributable to a human, service, or device principal acting under a current grant.

### 51.2 Membership and effective roles

TeamMembership binds principal, role codes, duty scopes, authority bases, conflict declarations, valid interval, and status. INVITED, ACTIVE, SUSPENDED, EXPIRED, and REVOKED are distinct. A member may hold duties without the grant to execute them, or a grant may be invalidated when required membership expires.

### 51.3 Responsibility and accountability assignment

ResponsibilityAssignment names work kind and subjects, exactly one accountable principal, responsible principals, consulted and informed principals, approval quorum, backups, service target, escalation path, interval, and status. Models and vehicle agents may be responsible for bounded work, but every high-impact assignment retains one accountable human principal.

### 51.4 Approval quorums and separation of duties

ApprovalMatrix declares proposer, reviewer, approver, quorum, prohibited role combinations, and emergency override rules by action class. Marketplace close, seller payout, title clearance, incident closure, rights override, moderation appeal, and financial reconciliation can require distinct principals. A policy-required separation MUST NOT collapse because the team is small; the action waits, escalates, or uses an independently authorized service.

### 51.5 Delegation, escalation, and emergency access

Delegation and subdelegation only attenuate asset, action, field, purpose, geography, time, amount, tool, and risk scope. Emergency access is a separately declared path with trigger, duration, exact permissions, approval/notification, audit, and mandatory after-review. It cannot become standing access through repeated renewal.

### 51.6 Handoff, absence, offboarding, and succession

ManagementHandoffReceipt binds outgoing and incoming principals, responsibilities, open cases, actions, unknown effects, credentials/epochs, acknowledgement time, and unresolved items. Offboarding advances relevant membership, grant, session, connector, and management epochs before dispatch. A missed handoff invalidates dependent decisions instead of silently assigning work to whoever remains online.

# 52. Tax applicability, accounting-entity boundaries, and reporting assertions

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.52 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:2756e108c76908c391b01ca5ec20cf958bfe6ee174a888a84bd38d1102a4ffb2

Vehicle income may arise from auctions, rentals, robo-taxi missions, sponsorships, content, tickets, merchandise, training, referrals, licensing, data rights, or service work. RTracer records economic facts and attributed determinations without claiming to be the final authority in every jurisdiction.

### 52.1 Accounting entity and legal account holder

AccountingEntityBoundary names the legal account-holder principal, external accounting-entity assertions, controlled accounts, provider accounts, chart and journal policy locks, reporting currencies, period policy, and state. Vehicle identity, persona beneficiary, bank-account owner, seller, taxpayer, employer, and platform tenant may be different principals.

Accounts and journals MUST NOT net across legal account holders or currencies. A vehicle may receive a beneficiary allocation while funds and reporting duties remain with a named human or legal entity.

### 52.2 Transaction tax context

TaxApplicabilityContext binds the economic event, potentially relevant subjects and counterparties, event nature, supplied assets/services/rights, location assertions, jurisdictions considered, amounts, exemptions or statuses, missing/disputed inputs, and context digest. GPS alone does not establish place of supply, residence, establishment, registration, import, use, or tax treatment.

### 52.3 External or rules-engine determination

TaxDeterminationAssertion names producer and functional role, ruleset/provider, ruleset digest, exact input-context digest, line determinations, rounding policy, responsibility allocations, limitations, result, effective time, and expiry. QUOTED, ACCEPTED_FOR_TRANSACTION, INDETERMINATE, DISPUTED, and SUPERSEDED remain distinct.

### 52.4 Invoices, credit notes, and reporting documents

TaxDocumentAssertion binds document kind, issuer, recipient, period, native identifier, artifact digest, amount/tax lines, source provider, native status, and correction lineage. Quote, invoice, receipt, credit note, journal, filing, withholding evidence, remittance evidence, and external authority status MUST NOT be substituted for one another.

### 52.5 Withholding, remittance, and reconciliation assertions

Withholding and remittance are attributed effects with payer/provider, amount, currency, period, authority reference, provider receipt, and reconciliation status. UNKNOWN_EFFECT semantics apply when an external submission may have succeeded. Accounting records retain reservations and reconciliation duties until the effect is proven.

### 52.6 Corrections and cross-entity prohibitions

Corrections append SUPERSEDED plus replacement determinations or documents. Posted journals are reversed and replaced through balanced entries. The platform MUST NOT edit a historical tax result, net one entity’s payable against another’s revenue, or imply that a platform estimate is an official final position.

# 53. Operational, security, privacy, financial, and safety incident response

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.53 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:81acd39d32af82bffbc538ea4b2867d33791317112c9ef956e91cb2ecb5695fd

An embodied-machine platform can experience conventional service incidents and incidents that touch private location, physical safety, auctions, payments, vehicle control, telemetry provenance, youth protection, or external provider effects. Incident response is therefore typed casework with scoped emergency powers, evidence preservation, reconciliation, notification assessment, and corrective action.

### 53.1 Incident declaration and classification

IncidentCase binds incident kinds, severity, affected subjects and tenants, occurrence interval, discovery time, reporter, accountable principal, incident commander, response team, evidence holds, external effects, policy lock, and projected state. Detection is not confirmation. False positives and merged incidents remain recorded outcomes.

### 53.2 Severity, command, and response team

Severity and command changes append through authorized transitions with evidence. Incident roles are time-bound functional assignments; response-team membership is not tenant-wide access. Safety, privacy, security, financial, market, and communications responsibilities can have separate accountable principals under one incident commander.

### 53.3 Evidence preservation and containment

IncidentTimelineEntry records actor, event kind, occurrence and record times, evidence, before/after state, uncertainty, and correlations. Containment actions use exact target selectors, expiry, risk, authorization, and rollback conditions. Emergency credentials, profile freezes, connector disables, market halts, location suppression, or command fences are narrow and audited.

### 53.4 Recovery and external-effect reconciliation

Recovery proves restored records/artifacts, state checkpoints, credential epochs, affected projections, provider effects, market state, accounting reservations, and safety-control separation. An unresolved payment, dispatch, title change, auction close, physical command, or disclosure remains UNKNOWN_EFFECT or OPERATOR_REQUIRED and blocks incident closure where policy requires.

### 53.5 Notification assessment and communications

IncidentNotificationDecision names decider, advisor/authority assertions, audiences considered, policy lock, known-facts checkpoint, unknowns, result, reasons, deadlines or review time, and notice receipts. Results are NOTIFY, DO_NOT_NOTIFY, DEFER, or INDETERMINATE. Communication never outruns the evidence checkpoint and preserves protected investigative details.

### 53.6 Post-incident review and corrective actions

PostIncidentReview binds reviewers, evidence checkpoint, root-cause findings, contributing factors, failed and successful controls, corrective actions, remaining risks, and approval. Every corrective action has owner, due state, verification method, and closure evidence. An incident may reopen by decision when new evidence or failed remediation appears.

# 54. Auction institutions and market-integrity runtime

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.54 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:a4315549a4f18c5ad837230fc88ca2983741e58abc260361f869f3beeef1224a

Live bids on vehicle identities combine social reach, high-value assets, insider relationships, automated agents, external payments, and potentially regulated transfer. Market integrity therefore requires an operator mandate, preserved bids, private signals, independent review, serialized halts, appeal, and settlement suspension.

### 54.1 Auction-operator mandate

AuctionOperatorMandate binds operator principal, auction selectors, permitted and prohibited functions, separation rules, locked rule sets, valid interval, mandate epoch, and status. The operator cannot change admitted bids, choose a reserve after opening, bypass seller authority, or redefine settlement terms outside the locked auction stream.

### 54.2 Participant and related-party assertions

MarketPartyRelationshipAssertion records party references, relationship class, source evidence, interval, confidence/limitations, and state. Beneficial-owner, controller, household, employer, sponsor, agent, seller-controlled, and coordinated-party claims are attributed evidence. Missing relationship evidence is not proof of independence.

### 54.3 Integrity signals and surveillance

MarketIntegritySignal names auction/market, subject parties and bids, signal kinds, detector/version, input receipts, feature digest, optional score, uncertainty, generation time, and an explicit prohibition on automatic adverse action. Shared networks, devices, timing patterns, repeated increments, funding sources, identity links, or content campaigns are signals—not proof of collusion or shill bidding.

### 54.4 Integrity case and decision

Signals may open a confidential case. MarketIntegrityDecision binds reviewer, authority, policy lock, signals, evidence, exact scopes, outcome, reasons, effective interval, and appeal. Outcomes include NO_ACTION, MONITOR, REQUIRE_REVIEW, REJECT_NEW_BIDS, EXCLUDE_BID, PAUSE_AUCTION, CANCEL_AND_RELIST, RESTRICT_PARTICIPANT, SUSPEND_SETTLEMENT, and EXTERNAL_REFERRAL.

### 54.5 Serialized auction halt and release

MarketHalt references auction stream head and authority decision, pause policy, request/activation times, close-clock disposition, notices, release decision, and state. Activation and release serialize against bid admission and close. A halt cannot create, edit, delete, or reorder a bid. Publisher/feed delay never substitutes for the authoritative auction state.

### 54.6 Bid exclusion, appeal, and settlement suspension

Bid exclusion is a decision over eligibility, not mutation of the admission receipt. Appeals append through the case runtime. Evidence arriving after close preserves the close result while settlement may suspend. Any later confirmed outcome is expressed through explicit eligibility, close, compensation, refund, transfer, and accounting records.

# 55. Corrective operational profiles, release bundles, migration, and agent discovery

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.section.55 · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:43b397a8387fc832ca9677e6e467431cd00358919929ac8f36693869ef6c8416

Version 1.4 is a bounded correctness release. It keeps rtracer.record-core/1.3 canonical bytes and digests unchanged while versioning broken proof, receipt, ledger, event, projection, cursor, control, and action-dispatch profiles independently. Exact v1.4 operational profiles supersede conflicting illustrative shapes in earlier sections and Appendix D.

### 55.1 Profile precedence

The exact profiles are rtracer.proof-target/1.4, rtracer.ingest-receipt/1.4, rtracer.canonical-event/1.4, rtracer.ledger-checkpoint/1.4, rtracer.projection-checkpoint/1.4, rtracer.cursor/1.4, rtracer.authority-lease/1.4, rtracer.control-command/1.4, rtracer.command-disposition/1.4, and rtracer.action-dispatch/1.4. Implementations MUST NOT combine fields or digest rules from different profile versions.

### 55.2 Immutable release identity

The human edition is 1.4, the exact release is 1.4.0, and the documentation schema is 2.0.0. Exact release routes are immutable and canonical. Mutable discovery aliases identify themselves as aliases and expose the exact target. Accepted v1.3 bytes remain preserved and addressable.

### 55.3 Stable identities and semantic digests

Sections, headings, requirements, recipes, fixtures, schemas, and migrations use registered stable identifiers that are never recycled. A semantic digest covers schema version, stable ID, title, normative status, and blocks under the declared canonical JSON profile. Artifact SHA-256 covers exact published bytes. Release time and local build paths are excluded from semantic identity.

### 55.4 Migration classes

Every prior stable ID is classified exactly once as unchanged, modified, renamed, moved, split, merged, deprecated, or removed. Added IDs are listed separately. Changed content cannot be called unchanged. The migration record includes old/new titles and URLs, semantic digests, compatibility impact, replacements, affected fixtures, and explanation.

### 55.5 Human and agent entrypoints

Humans enter through the living /substrate/ landing page or an exact release route. Agents first resolve /substrate/versions.json, then the exact release manifest, section JSON/Markdown, schema, migration, and fixture artifacts. Agents cite stable ID, release version, semantic digest, and canonical exact URL. Scraping presentation HTML is a fallback, not the contract.

### 55.6 Release gates and two-implementation proof

A release is accepted only after deterministic double build, artifact hash verification, schema validation, fixture uniqueness and execution, legacy-byte preservation, cross-release migration coverage, full-text search tests, exact canonical routes, accessibility checks, and two independent implementations reproducing normative golden bytes and state results. A prose-only fixture list does not satisfy executable conformance.

# Appendix K. Institutional record catalog and functional-role vocabulary

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.appendix.k · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:1616ec9347c5617a1200621432f368f9ecacc337749d2d83cc98c2610bc1e80b

This appendix defines closed record bodies used by Sections 45–54. All are carried inside the existing RecordCore envelope and remain immutable. Domain packs may add namespaced extensions but MUST NOT remove authority, time, policy, evidence, conflict, or accountability fields.

### K1. Institution and external-source records

```text
InstitutionProfile {
  institutionId, principalId, declaredName, actorKinds[],
  legalIdentityAssertionRefs[], serviceEndpointRefs[],
  jurisdictionScopeRefs[], qualificationAssertionRefs[],
  status: UNVERIFIED|ACTIVE|RESTRICTED|SUSPENDED|RETIRED
}

InstitutionalRoleAssignment {
  assignmentId, institutionPrincipalId, functionalRole,
  issuerPrincipalId, authorityBasisRefs[], actionScopes[],
  subjectSelectors[], domainScopes[], jurisdictionScopes[],
  restrictions[], verificationState, validInterval,
  status: DRAFT|EVIDENCE_PENDING|ACTIVE|RESTRICTED|
          SUSPENDED|DISPUTED|EXPIRED|REVOKED
}

ExternalAuthorityQueryReceipt {
  queryId, sourceInstitutionId, endpointProfileRef,
  querySelectorDigest, requestedAssertionKinds[],
  requestedAt, respondedAt, responseArtifactDigest,
  result: MATCH|NO_MATCH|AMBIGUOUS|UNAVAILABLE|ERROR,
  sourceProofRefs[], freshnessPolicyRef
}

ExternalAuthorityAssertion {
  assertionId, issuerInstitutionId, nativeSystemRef,
  nativeRecordIdRef?, subjectRefs[], assertionKind,
  sourceValueArtifactRef, normalizedValue?, vocabularyRef,
  jurisdictionScopeRefs[], effectiveInterval, fetchedAt,
  validUntil?, sourceProofRefs[], transformationReceiptRef?,
  status: ASSERTED|SUPERSEDED|RETRACTED|DISPUTED|
          CONFLICTED|UNAVAILABLE
}
```

### K2. Common case records

```text
CaseFile {
  caseId, caseKind, subjectRefs[], participantRefs[],
  initiatingRecordRefs[], policyLock, jurisdictionContextRefs[],
  confidentialityPolicyRef, assignedTeamId?,
  accountablePrincipalId, reviewerRequirementRefs[], priority,
  openedAt, targetDates[], relatedCaseIds[], initialState
}

CaseTransition {
  transitionId, caseId, expectedCaseSequence, fromState, toState,
  triggerKind, actorPrincipalId, authorityAssignmentRef,
  decisionOrEvidenceRefs[], reasonCodes[], occurredAt
}

CaseEvidenceSubmission {
  submissionId, caseId, submitterPrincipalId,
  representedPartyId?, artifactRefs[], propositionRefs[],
  custodyRefs[], disclosureClass, privilegeOrRestrictionRefs[],
  submittedAt, admittedDisposition, challengeRefs[]
}

CaseDecision {
  decisionId, caseId, deciderPrincipalId, authorityAssignmentRef,
  conflictDeclarationRefs[], candidateOutcomes[], selectedOutcome,
  policyLock, evidenceSetDigest, findings[], reasonCodes[],
  effectiveScope, effectiveAt, expiryOrReviewAt?,
  noticeRequirements[], appealPolicyRef?, supersedesDecisionId?
}

CaseNotice {
  noticeId, caseId, decisionId?, recipientPrincipalId,
  contentArtifactDigest, disclosedReasonCodes[], channel,
  dispatchedAt, deliveryDisposition, providerReceiptRefs[],
  responseDeadline?
}

CaseAppeal {
  appealId, caseId, challengedDecisionId, appellantPrincipalId,
  representativeRef?, grounds[], evidenceRefs[], requestedOutcome,
  filedAt, timelinessDecisionRef?, reviewerRequirementRefs[],
  status: FILED|VALIDATING|ACCEPTED|REJECTED|REVIEWING|
          DECIDED|WITHDRAWN|CLOSED
}

CaseRemedy {
  remedyId, caseId, decisionId, remedyKind, targetRefs[],
  requiredActions[], prohibitedActions[], effectiveInterval,
  responsiblePrincipalId, verificationRequirements[],
  completionRefs[], status
}
```

### K3. Registry and transfer records

```text
TitleInterestAssertion {
  titleInterestId, assetId, holderPrincipalRefs[], interestClass,
  issuerAssertionRef, nativeStatus, effectiveInterval,
  priorityOrOrderAssertion?, restrictionRefs[],
  status: ASSERTED|SUPERSEDED|RELEASED|DISPUTED
}

EncumbranceAssertion {
  encumbranceId, assetId, interestedPrincipalRefs[], encumbranceClass,
  issuerAssertionRef, amountRef?, effectiveInterval,
  releaseAssertionRef?, nativeStatus,
  status: ASSERTED|RELEASE_PENDING|RELEASED|SUPERSEDED|DISPUTED
}

RegistryRestrictionAssertion {
  restrictionId, assetId, restrictionKind, issuerAssertionRef,
  affectedActions[], configurationOrOperationScope?,
  effectiveInterval, reviewOrExpiryAt?,
  status: ACTIVE|CLEARED|SUPERSEDED|DISPUTED
}

TransferClearanceDecision {
  clearanceId, assetId, proposedTransferId, policyLock,
  requiredCheckKinds[], queryReceiptRefs[], titleInterestRefs[],
  encumbranceRefs[], restrictionRefs[], sellerAuthorityDecisionRef,
  missingInputs[], conflictRefs[], staleInputs[],
  result: CLEAR_FOR_PLATFORM_STEP|CONDITIONAL|BLOCKED|INDETERMINATE,
  conditions[], decidedBy, effectiveAt, expiresAt
}
```

### K4. Insurance and repair records

```text
InsuranceContractAssertion {
  contractAssertionId, insurerInstitutionId, nativeContractIdRef,
  insuredPrincipalRefs[], assetId, configurationSelector?,
  operationAndUseScopes[], territoryScopes[], coveragePeriod,
  coverageTermsArtifactRef, limitAndDeductibleRefs[],
  sourceAssertionRef,
  status: ASSERTED_ACTIVE|ASSERTED_SUSPENDED|ASSERTED_EXPIRED|
          ASSERTED_CANCELLED|DISPUTED
}

LossNotice {
  lossNoticeId, incidentId, assetId, asOperatedConfigurationId,
  notifyingPrincipalId, claimantPrincipalRefs[], occurredInterval,
  privateLocationRef?, damageAndConditionRefs[], evidenceRefs[],
  insurerSubmissionRefs[], status: DRAFT|SUBMITTED|ACKNOWLEDGED|WITHDRAWN
}

CoverageDecision {
  coverageDecisionId, claimCaseId, insurerInstitutionId,
  authorityAssignmentRef, contractAssertionRefs[],
  consideredLossScopes[], excludedOrUnresolvedScopes[],
  evidenceSetDigest, policyOrTermsDigest,
  result: ACCEPTED|PARTIAL|DECLINED|PENDING|INDETERMINATE,
  conditions[], amountCaps[], reasonCodes[], effectiveAt,
  reviewAndAppealPolicyRef
}

LossAssessment {
  assessmentId, claimCaseId, assessorPrincipalId,
  authorityOrQualificationRefs[], assetId, configurationId,
  inspectionProcedureRef, evidenceRefs[], damageMapRefs[],
  causalHypotheses[], repairabilityClass, repairCostEstimateRefs[],
  valueEstimateRefs[], uncertainty, limitations[], conflictRefs[]
}

RepairEstimate {
  estimateId, claimCaseId?, workPackageId, repairerPrincipalId,
  configurationId, lineItems[], laborItems[], partsRefs[],
  taxesAndFees[], currency, total, assumptions[], exclusions[], validUntil
}

RepairAuthorization {
  authorizationId, claimCaseId?, estimateId, authorizerPrincipalId,
  authorityBasisRefs[], payerOrBeneficiaryRefs[], approvedScope[],
  excludedScope[], amountCapsByCurrency[], partAndProcedureConstraints[],
  deviationPolicy, effectiveInterval, amendmentOf?
}

RepairCompletion {
  completionId, authorizationId?, workPackageExecutionId,
  resultingConfigurationId, deviations[], installedPartRefs[],
  measurementAndInspectionRefs[], invoiceArtifactRefs[],
  releaseDecisionRef?, completedAt
}
```

### K5. Moderation and youth-protection records

```text
ModerationReport {
  reportId, reporterPrincipalId?, subjectRefs[],
  contentOrInteractionRefs[], categoryCodes[], evidenceRefs[],
  urgency, safetyAndPrivacyFlags[], requestedOutcome?, receivedAt
}

ModerationDecision {
  moderationDecisionId, caseId, decisionMakerPrincipalId,
  reviewerType, policyLock, evidenceSetDigest,
  outcome: NO_ACTION|LABEL|VISIBILITY_LIMIT|INTERACTION_LIMIT|
           CONTENT_RESTRICT|ACCOUNT_RESTRICT|PROFILE_FREEZE|
           MARKET_HALT|EXTERNAL_REFERRAL,
  exactTargetSelectors[], reasonCodes[], effectiveAt, expiresAt?,
  noticePolicyRef, appealPolicyRef
}

EmergencyRestriction {
  restrictionId, caseId, exactTargetSelectors[],
  immediateRiskReasonCodes[], issuerPrincipalId, imposedAt,
  automaticExpiryAt, mandatoryReviewBy, replacementDecisionId?,
  status: ACTIVE|EXPIRED|REPLACED|LIFTED
}

AgeAssuranceAssessment {
  assessmentId, subjectPrincipalId, methodClass, providerAssertionRef?,
  result: AGE_UNKNOWN|PROTECTED_AGE_BAND|NON_PROTECTED_AGE_BAND|
          INDETERMINATE,
  assuranceClass, jurisdictionContextRefs[], policyLock,
  assessedAt, expiresAt, minimizedSourceDataReceiptRef
}

GuardianAuthorityAssertion {
  guardianAuthorityId, protectedPrincipalId, guardianPrincipalId,
  issuerOrVerifierRef, basisAssertionRefs[], potentiallyGrantableScopes[],
  jurisdictionContextRefs[], validInterval, conflictRefs[],
  status: PENDING|ACTIVE|SUSPENDED|DISPUTED|EXPIRED|REVOKED
}

YouthProtectionProfile {
  profileId, protectedPrincipalId, ageAssessmentRef, policyLock,
  discoverabilityRule, messagingRule, locationPrecisionRule,
  advertisingRule, commerceRule, publicationApprovalRule,
  modelTrainingRule, effectiveInterval
}
```

### K6. Management-team records

```text
ManagementTeam {
  teamId, declaredName, beneficiaryIds[], managedSubjectSelectors[],
  charterRef, requiredFunctionalRoles[], separationRules[],
  escalationPolicyRef,
  status: FORMING|ACTIVE|DEGRADED|SUSPENDED|RETIRED
}

TeamMembership {
  membershipId, teamId, principalId, roleCodes[], dutyScopes[],
  authorityBasisRefs[], validInterval, conflictDeclarationRefs[],
  status: INVITED|ACTIVE|SUSPENDED|EXPIRED|REVOKED
}

ResponsibilityAssignment {
  responsibilityId, teamId, workKind, subjectSelectors[],
  accountablePrincipalId, responsiblePrincipalIds[],
  consultedPrincipalIds[], informedPrincipalIds[], approvalQuorumRef?,
  backupPrincipalIds[], serviceTargetRef?, escalationPath[],
  validInterval, status
}

ApprovalMatrix {
  approvalMatrixId, teamId, actionClasses[], proposerRules[],
  reviewerRules[], approverRules[], quorumRules[],
  prohibitedRoleCombinations[], emergencyOverridePolicyRef,
  version, digest
}

ManagementHandoffReceipt {
  handoffId, teamId, outgoingPrincipalIds[], incomingPrincipalIds[],
  responsibilityRefs[], openCaseIds[], openActionIds[],
  unknownEffectIds[], credentialAndEpochActions[], acknowledgedAt,
  unresolvedItems[]
}
```

### K7. Tax, incident, and market-integrity records

```text
AccountingEntityBoundary {
  boundaryId, legalAccountHolderPrincipalId,
  accountingEntityAssertionRefs[], controlledAccountIds[],
  providerAccountRefs[], chartOfAccountsLock, journalPolicyLock,
  reportingCurrencyRefs[], periodPolicyRef, status
}

TaxApplicabilityContext {
  contextId, economicEventId, taxSubjectPrincipalRefs[],
  counterpartyRoleRefs[], eventNature, assetServiceAndRightRefs[],
  supplyDeliveryUseLocationAssertions[], jurisdictionContextsConsidered[],
  amountsByCurrency[], exemptionOrSpecialStatusRefs[],
  missingOrDisputedInputs[], contextDigest
}

TaxDeterminationAssertion {
  determinationId, contextId, producerPrincipalId, producerRole,
  rulesetOrProviderRef, rulesetDigest, inputContextDigest,
  lineDeterminations[], roundingPolicyRef, responsibilityAllocations[],
  limitations[], result: QUOTED|ACCEPTED_FOR_TRANSACTION|
  INDETERMINATE|DISPUTED|SUPERSEDED, effectiveAt, expiresAt?
}

TaxDocumentAssertion {
  documentAssertionId, economicEventId, documentKind,
  issuerPrincipalId, recipientPrincipalRefs[], periodRef?,
  nativeDocumentIdRef, artifactDigest, amountAndTaxLines[],
  sourceProviderRef, nativeStatus, correctionOf?
}

IncidentCase {
  incidentId, incidentKinds[], severity, affectedSubjectRefs[],
  affectedTenantRefs[], occurredInterval?, discoveredAt,
  reporterPrincipalId, accountablePrincipalId, incidentCommanderId,
  responseTeamId, evidenceHoldRefs[], externalEffectRefs[],
  policyLock, currentProjectedState
}

IncidentTimelineEntry {
  entryId, incidentId, entryKind, actorPrincipalId,
  occurredAt, recordedAt, evidenceRefs[], beforeState?, afterState?,
  uncertainty?, correlationRefs[]
}

IncidentNotificationDecision {
  decisionId, incidentId, decidingPrincipalId,
  advisorOrAuthorityAssertionRefs[], audiencesConsidered[], policyLock,
  knownFactsCheckpoint, unknowns[],
  result: NOTIFY|DO_NOT_NOTIFY|DEFER|INDETERMINATE,
  reasonCodes[], deadlinesOrReviewAt?, noticeReceiptRefs[]
}

PostIncidentReview {
  reviewId, incidentId, reviewerIds[], evidenceCheckpoint,
  rootCauseFindings[], contributingFactors[], controlFailures[],
  successfulControls[], correctiveActionIds[], remainingRisks[], approvedAt
}

AuctionOperatorMandate {
  mandateId, auctionOperatorPrincipalId, auctionSelectors[],
  permittedFunctions[], prohibitedFunctions[], separationRules[],
  ruleSetRefs[], validInterval, mandateEpoch, status
}

MarketPartyRelationshipAssertion {
  relationshipAssertionId, partyRefs[], relationshipClass,
  sourceAssertionRefs[], effectiveInterval, confidenceAndLimitations,
  status: ASSERTED|DISPUTED|SUPERSEDED|RETRACTED
}

MarketIntegritySignal {
  signalId, marketOrAuctionId, subjectPartyRefs[], subjectBidRefs[],
  signalKinds[], detectorRef, detectorVersion, inputReceiptRefs[],
  featureDigest, scoreOrOrdinal?, uncertainty, generatedAt,
  adverseActionProhibited: true
}

MarketIntegrityDecision {
  decisionId, caseId, reviewerPrincipalId, authorityAssignmentRef,
  policyLock, signalRefs[], evidenceRefs[],
  outcome: NO_ACTION|MONITOR|REQUIRE_REVIEW|REJECT_NEW_BIDS|
           EXCLUDE_BID|PAUSE_AUCTION|CANCEL_AND_RELIST|
           RESTRICT_PARTICIPANT|SUSPEND_SETTLEMENT|EXTERNAL_REFERRAL,
  exactScopes[], reasonCodes[], effectiveAt, expiresAt?, appealPolicyRef
}

MarketHalt {
  haltId, auctionId, expectedAuctionStreamHead, authorityDecisionRef,
  pausePolicyRef, requestedAt, activatedAt, closeClockDisposition,
  bidderNoticeRefs[], releaseDecisionRef?,
  status: REQUESTED|ACTIVE|RELEASED|CANCELLED
}
```

### K8. Functional-role starter vocabulary

| Vocabulary family | Example functional roles |
| --- | --- |
| registry and title | registry_source, title_reviewer, lien_source, theft_source, recall_source, transfer_clearance_decider |
| insurance and repair | insurer, claims_handler, loss_assessor, repair_estimator, repair_authorizer, repairer, safety_inspector |
| community and protection | moderation_triager, moderation_reviewer, appeal_reviewer, youth_safety_reviewer, guardian_verifier |
| team and operations | vehicle_steward, maintenance_manager, race_engineer, media_manager, sponsorship_manager, incident_commander |
| markets and finance | auction_operator, market_integrity_reviewer, settlement_reconciler, accountant, tax_determination_provider |
| safety and control | control_authority_issuer, safety_release_decider, mission_supervisor, emergency_responder |

# Appendix L. Institutional invariants and state-transition matrices

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.appendix.l · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:47a1268118f43d61dd3f3a9f3e250a517f3c6dd56f23bfa21869f227af800c02

### L1. Required state machines

```text
Institutional role
DRAFT -> EVIDENCE_PENDING -> ACTIVE
ACTIVE -> RESTRICTED | SUSPENDED | DISPUTED | EXPIRED | REVOKED
SUSPENDED | DISPUTED -> ACTIVE only through a new review decision

Common case
INTAKE -> VALIDATING -> OPEN -> INVESTIGATING
INVESTIGATING <-> AWAITING_PARTY
INVESTIGATING -> DECISION_PENDING -> DECIDED
DECIDED -> NOTICE_PENDING -> NOTIFIED -> APPEAL_WINDOW -> FINAL
APPEAL_WINDOW -> APPEALED -> REVIEWING
REVIEWING -> AFFIRMED | MODIFIED | VACATED | REMANDED
Any nonterminal state -> WITHDRAWN | DISMISSED | STAYED
FINAL -> REOPENED only through a separately authorized decision

Registry clearance
UNREQUESTED -> QUERYING -> ASSERTIONS_COLLECTED
ASSERTIONS_COLLECTED -> REVIEW_READY | CONFLICTED | STALE | INCOMPLETE
REVIEW_READY -> CLEAR | CONDITIONAL | BLOCKED | INDETERMINATE
Any new relevant assertion invalidates the prior clearance projection

Insurance claim
NOTICE_DRAFT -> SUBMITTED -> ACKNOWLEDGED -> INVESTIGATING
-> COVERAGE_PENDING -> ASSESSMENT -> REPAIR_AUTH_PENDING
-> REPAIRING -> INSPECTING -> SETTLING -> CLOSED
Any reviewable state -> DISPUTED | APPEALED | WITHDRAWN

Repair
PROPOSED -> ESTIMATED -> AUTHORIZED -> IN_PROGRESS
IN_PROGRESS -> SUSPENDED | COMPLETED
COMPLETED -> INSPECTED -> RELEASED
Changed scope, amount, parts, or procedure -> AMENDMENT_REQUIRED

Moderation
RECEIVED -> TRIAGED -> PRESERVED -> REVIEWING
REVIEWING -> NO_ACTION | ACTION_PROPOSED
ACTION_PROPOSED -> DECIDED -> NOTIFIED -> APPEAL_WINDOW -> FINAL
Emergency: RECEIVED -> TEMPORARILY_RESTRICTED -> MANDATORY_REVIEW
-> REPLACED_BY_DECISION | LIFTED | EXPIRED

Guardian authority
PENDING -> ACTIVE
ACTIVE -> SUSPENDED | DISPUTED | EXPIRED | REVOKED
SUSPENDED | DISPUTED -> ACTIVE only through new verification

Tax
CONTEXT_OPEN -> INPUT_COMPLETE -> DETERMINATION_PENDING
-> QUOTED -> ACCEPTED_FOR_TRANSACTION -> DOCUMENT_PENDING
-> DOCUMENTED -> RECONCILED
Any state -> INDETERMINATE | DISPUTED

Incident
DETECTED -> TRIAGED -> DECLARED -> CONTAINING
-> CONTAINED -> RECOVERING -> MONITORING -> CLOSED
TRIAGED -> FALSE_POSITIVE | MERGED
Any post-declaration state -> EXTERNAL_COORDINATION
CLOSED -> REOPENED through a new decision

Market integrity
SIGNALLED -> TRIAGED -> MONITORING | CASE_OPENED | DISMISSED
CASE_OPENED -> INVESTIGATING -> DECISION_PENDING
-> ACTIONED | CLEARED -> APPEAL_WINDOW -> CLOSED
Auction halt: REQUESTED -> ACTIVE -> RELEASED | CANCELLED
```

### L2. Invariants H-45 through H-80

| ID | Invariant |
| --- | --- |
| H-45 | Institution identity, brand, title, or declared role creates no authority. |
| H-46 | Every institutional action binds a current functional-role assignment and explicit grant. |
| H-47 | An authenticated external response proves source and bytes, not physical or legal truth. |
| H-48 | No response, unavailable response, or NO_MATCH never means no lien, restriction, or title conflict. |
| H-49 | Stale, conflicted, or indeterminate institutional inputs cannot authorize R3/R4 effects. |
| H-50 | Native issuer values remain preserved; normalized values are versioned derivations. |
| H-51 | Every high-impact case has one named accountable principal. |
| H-52 | Every decision binds policy digest, evidence checkpoint, authority, exact scope, and reason codes. |
| H-53 | Case state changes append; decisions and evidence are never edited away. |
| H-54 | Notice disclosure is minimized and does not improperly expose reporters, victims, or protected signals. |
| H-55 | Appeals create new review records and cannot mutate the challenged decision. |
| H-56 | Reviewer independence, deadlines, and remedies come from pinned policy packs. |
| H-57 | Registry identity, title interest, encumbrance, restriction, seller authority, and clearance remain distinct. |
| H-58 | Payment, custody, possession, or profile control cannot satisfy title clearance. |
| H-59 | New relevant registry evidence invalidates dependent clearance projections. |
| H-60 | Platform clearance is scoped and time-limited, never universal legal truth. |
| H-61 | Coverage is never inferred from an active-looking policy, payment, telemetry, or relationship. |
| H-62 | Loss assessment, estimate, authorization, execution, release, and reimbursement remain distinct. |
| H-63 | Work outside authorization scope or cap requires an appended amendment. |
| H-64 | Insurer, assessor, and repairer access only explicitly authorized projections. |
| H-65 | Moderation actions have exact targets, policy basis, accountable decider, and review interval. |
| H-66 | Emergency restrictions expire automatically unless replaced by a reviewed decision. |
| H-67 | Unknown or indeterminate age invokes the selected child-safe default. |
| H-68 | Guardian assertion neither authenticates the guardian nor grants an action by itself. |
| H-69 | Exact birth data is excluded from public, ad, agent-context, and training projections by default. |
| H-70 | A management team is not a principal; membership is not authority. |
| H-71 | Every responsibility assignment has exactly one accountable principal. |
| H-72 | Delegation and subdelegation can only attenuate scope. |
| H-73 | Offboarding, expiry, and missed handoff invalidate dependent dispatch decisions. |
| H-74 | Policy-separated proposer, reviewer, approver, close, and reconciliation roles cannot collapse. |
| H-75 | Tax quote, invoice, journal, withholding, remittance, and authority status are distinct. |
| H-76 | Accounts and journals never net across legal account holders or currencies. |
| H-77 | Every tax result names producer, ruleset, input digest, limitations, and effective time. |
| H-78 | Incident changes append; response access is scoped; closure needs recovery evidence and owned actions. |
| H-79 | Market-integrity signals are private evidence, never guilt, reputation, or automatic adverse action. |
| H-80 | Exclusion, restriction, and halt require attributable decisions and serialize against auction close. |

# Appendix M. Forty institutional conformance fixtures

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.appendix.m · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:69459f30145d8c57254a9417bd6fead82e6f4f76dfaf5f26305b086c0c77ff77

Every fixture has a machine-readable companion carrying pre-state, exact input records, acting principal/grants, policy lock, expected admitted/rejected records, state vector, reason codes, and projection digest. The table is the human oracle summary.

### M1. Registry and title

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-257 | Authenticated registry query returns NO_MATCH. | Retain receipt; clearance remains INDETERMINATE. |
| T-258 | Two current issuers assert incompatible title interests. | Retain both, open conflict case, and block transfer. |
| T-259 | A release assertion predates a newer encumbrance. | Do not project no lien. |
| T-260 | Claimant proves custody but lacks may_list_for_sale. | Deny listing. |
| T-261 | Registry source times out during settlement. | Suspend title review and preserve funds per settlement policy. |
| T-262 | Source role expired before its assertion. | Preserve bytes; exclude it from clearance. |

### M2. Insurance, assessment, and repair

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-263 | Insurer requests defect telemetry without an exact disclosure grant. | Deny. |
| T-264 | Contract appears active but operation/configuration scope is unknown. | Coverage remains INDETERMINATE. |
| T-265 | Assessor and repairer are the same principal where independence is required. | Block assessment acceptance. |
| T-266 | Teardown raises estimate beyond authorization cap. | Enter AMENDMENT_REQUIRED. |
| T-267 | Repair completes without insurer authorization. | Preserve work history; do not fabricate authorization or reimbursement. |
| T-268 | Payment occurs before a coverage appeal. | Append journals and appeal independently. |

### M3. Moderation and appeals

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-269 | Automated detector permanently removes a listing without required review. | Reject enforcement. |
| T-270 | Emergency restriction lacks expiry or review time. | Reject restriction. |
| T-271 | Reporter response would reveal a protected suppression rule. | Return a generic, non-revealing notice. |
| T-272 | Appeal is assigned to the original reviewer despite independence policy. | Reject assignment. |
| T-273 | Decision attempts to delete original content bytes. | Deny mutation; apply projection restriction. |
| T-274 | New policy is substituted retroactively into an old decision. | Preserve old decision; create explicit re-review. |

### M4. Youth and guardianship

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-275 | Age is unknown and a stranger requests messaging plus behavioral ads. | Child-safe default denies both. |
| T-276 | Untrusted source claims guardian status. | Preserve assertion; issue no guardian grant. |
| T-277 | Guardian authority is revoked while publication and purchase are scheduled. | Freeze both and reevaluate. |
| T-278 | Protected user crosses an age threshold. | Create new protection decision; do not publish history. |

### M5. Delegated teams

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-279 | Active team membership is presented as sale authority. | Deny. |
| T-280 | One manager proposes and approves their payout despite separation policy. | Deny. |
| T-281 | Subdelegate receives broader asset, time, or amount scope. | Reject grant. |
| T-282 | Offboarded manager uses a still-valid session at dispatch. | Reject by epoch; record handoff failure. |

### M6. Tax and accounting

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-283 | GPS alone selects tax treatment. | Return INDETERMINATE. |
| T-284 | Tax quote is presented as proof of remittance. | Reject record-type substitution. |
| T-285 | One entity’s payable nets against another’s revenue. | Reject journal. |
| T-286 | Revised tax result edits a posted batch. | Reject mutation; append reversal/replacement. |

### M7. Incident response

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-287 | Severity is lowered without evidence and decision. | Reject transition. |
| T-288 | Closure is requested with unknown provider effect. | Enter OPERATOR_REQUIRED. |
| T-289 | Notification decision omits policy lock or decider. | Reject decision. |
| T-290 | Responder requests tenant-wide telemetry without scope. | Deny. |
| T-291 | Post-incident remediation lacks owner or due state. | Fail closure gate. |

### M8. Market integrity

| ID | Scenario | Expected semantic result |
| --- | --- | --- |
| T-292 | Seller-controlled related party submits bids. | Open case; exclude only through policy-bound decision. |
| T-293 | Two bidders share an IP address. | Signal only; no automatic exclusion. |
| T-294 | Model score attempts to cancel an auction. | Deny; require authorized serialized halt. |
| T-295 | Relationship evidence arrives after close but before settlement. | Preserve close; suspend and adjudicate settlement. |
| T-296 | Appeal attempts to edit an excluded bid receipt. | Reject mutation; append appeal and eligibility decision. |

# Appendix N. v1.3 to v1.4 corrective migration and errata

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.appendix.n · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:1ca61a0798dab74ac09eed188334ec4578a45b4ea8ca4c3b21a9deedd66fe3b7

Version 1.4 is additive for the semantic vehicle model and corrective for operational runtime profiles. It does not renumber or redigest v1.3 RecordCore objects, receipts, proofs, events, or artifacts. It seals legacy operational histories and begins new profile epochs with explicit bridges.

### N1. Corrected contradictions and precedence

| v1.3 surface | Defect | v1.4 correction | Compatibility |
| --- | --- | --- | --- |
| 26.2, 30.2–30.6, 34.1–34.5, Appendix D1 | Tenant ledger_seq, shardPosition, stream receipt tail, and shard receipt chain describe competing order models. | commitSequence is gap-free per logical shard epoch; ShardHead owns the receipt tail; shardPosition is legacy storage metadata. | writer migration required; historical bytes preserved |
| 43.5 event topic table | Admission events partition by semantic stream while checkpoints advance by shard. | Canonical admission lane partitions by tenant + logicalShardId + chainEpoch and publishes commitSequence order. | consumer and broker migration required |
| 25.4, 33.4, 33.6, Appendix D2 | Required signer/suite/time/key fields are not all inside one signed target. | ProofTargetV1_4 signs the complete proof intent under one domain-separated digest; protected headers must match. | proof verifiers support both profiles |
| 34.3, 43.2 | Request digest does not exactly bind semantic headers and detached proof set; unknown-result lookup is absent. | RequestDigestInput is exact and /v1/idempotency:resolve is authenticated and scoped. | SDK/API addition; existing bindings preserved |
| 44.5 recovery | Empty projections may start from restored nonzero checkpoints. | Restore matching state+checkpoint or empty state+genesis only. | runbook correction |
| H-42, 34.6, T-076 | Absolute rebuildability conflicts with lawful payload/key destruction. | ErasureReceipt and ReplayTombstone yield NON_REPRODUCIBLE_BY_POLICY where required bytes no longer exist. | projection status addition |
| 39.1–39.2 | Bare monotonic lease time is not comparable across arbiters or reboot-safe. | AuthorityClockRef binds arbiter, clock, boot, tick rate, authority epoch, and anti-rollback state. | control profile migration required |
| 41.4, H2 | One-time dispatch nonce has no atomic consumption boundary. | ActionDispatchEnvelope and DISPATCHING append consume the nonce before provider I/O. | action broker migration required |
| documentation generator | Version/path literals, unstable block IDs, invalid Markdown tables, partial search, and incomplete manifests. | Exact immutable releases, identity registry, valid tables, body search, migration/deprecation records, artifact hashes, and schema publication. | documentation client update |

Where an old illustrative shape conflicts with an exact v1.4 profile, the v1.4 profile governs. Appendix D is retained as historical design context and MUST be interpreted through Appendix O for new implementations.

### N2. Ledger cutover procedure

Freeze each v1.3 logical shard’s writer and record the cutover policy, time, writer epochs, registry locks, and software digests. 2. Audit all legacy rows, per-stream sequence continuity, receipt links, proof availability, referenced artifacts, and outbox completeness. Any unexplained discrepancy blocks promotion and opens an incident. 3. Emit an immutable LegacyShardSeal over legacy receipt digests in legacy committed order. Preserve the exact ordering rule and any known gaps or ambiguities inside the seal. 4. Never renumber or redigest v1.3 records, proofs, receipts, events, cursors, or artifacts. 5. Create v1.4 chainEpoch 1 with commitSequence 1 and genesisPreviousDigest equal to the accepted LegacyShardSeal digest. 6. Preserve idempotency bindings and their original receipts. A retry resolves to the original profile unless a new intended operation is explicitly created. 7. Invalidate v1.3 query cursors at cutover. Do not translate private cursor state across cryptographic profiles. 8. Expire and fence all v1.3 control leases and in-flight commands. New AuthorityClockRef and authority epoch are required before arming. 9. Dual-read legacy and new profiles, shadow-verify v1.4 writes, then cut over writers. Derived projections expose their mixed-source checkpoint vector. 10. Sign and publish a MigrationReceipt containing seals, new genesis/epoch values, validation results, fixture bundle digest, responsible principals, and release manifest digest.

### N3. Stable identity migration

All 56 v1.3 section stable IDs remain registered. Modified sections include 25, 26, 30, 32, 33, 34, 39, 41, 43, 44, and Appendix D because their operational precedence or shapes change. Sections 45–55 and Appendices K–Q are added. No stable ID is removed or reused. Every existing fixture ID T-001 through T-256 remains unique; fixtures T-257 through T-328 are added.

### N4. Compatibility status

| Consumer | v1.4 behavior |
| --- | --- |
| semantic RecordCore reader | may continue reading 1.3 bytes unchanged |
| proof verifier | verifies only the profile declared by the proof; never auto-upgrades |
| ledger writer | must implement ShardHead, gap-free commitSequence, exact receipt profile, and bridge cutover |
| event consumer | must distinguish canonical admission lane from derived topics and checkpoint only canonical commitSequence |
| projection rebuilder | must declare replay mode, registry/code/policy locks, and erasure behavior |
| control runtime | must reject legacy bare-clock leases after cutover |
| agent/SDK | resolves exact release manifest and profile versions; does not infer latest semantics from an unversioned page |

# Appendix O. Exact v1.4 proof, ledger, event, projection, cursor, control, and dispatch profiles

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.appendix.o · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:6f2d65d137d2fd612cd1d87aac3999df82694bf371744abdc25205d2926e1426

### O1. Proof target

```text
ProofTargetV1_4 {
  profile, proofId, targetKind, targetId,
  targetProfile, targetDigest, auxiliaryDigests[],
  proofPurpose, signerPrincipalId, verificationMethodId,
  keyEpoch, suite, createdAt, validUntil?, audience?, challenge?
}

proofTargetDigest = SHA256(
  "RTRACER\0PROOF-TARGET\0v1.4\0" || JCS(ProofTargetV1_4)
)
```

Every listed field is inside the digest. auxiliaryDigests are sorted by their declared semantic key before canonicalization. COSE protected headers repeat suite, verification method/key ID and epoch, content type, and profile; each repeated value MUST match the target. A mismatch is RTR-PROOF-TARGET-MISMATCH or RTR-PROOF-ALGORITHM-CONFUSION, never a fallback to another algorithm.

### O2. Shard head, commit order, and receipt

```text
ShardHead {
  ledgerId, tenantId, logicalShardId, chainEpoch,
  lastCommitSequence, lastReceiptDigest,
  publisherEpoch, shardMapVersion
}

IngestReceiptV1_4 {
  receiptProfile, receiptId, ledgerId, tenantId,
  logicalShardId, chainEpoch, commitSequence,
  shardMapVersion, streamId, streamSequence,
  recordId, recordDigest, admissionDecision, findingCodes[],
  receivedAt, committedAt, writerEpoch,
  previousReceiptDigest, validatorSetDigest,
  schemaRegistrySnapshotDigest, policyDecisionRef,
  canonicalAdmissionEventId, storeId, storeWorkloadIdentity,
  receiptDigest, storeProofRef
}

receiptDigest = SHA256(
  "RTRACER\0INGEST-RECEIPT\0v1.4\0" ||
  JCS(receipt_without_receiptDigest_and_storeProofRef)
)
```

commitSequence is a transactional, gap-free uint64 inside ledgerId + tenantId + logicalShardId + chainEpoch. shardPosition may remain a nonsemantic physical locator for legacy storage, but it MUST NOT drive receipt chaining, event ordering, checkpointing, cursors, or user-visible chronology.

The first receipt in an epoch references a defined genesis digest or signed epoch bridge. Every later receipt’s previousReceiptDigest equals the immediately preceding receiptDigest. Replication produces a CustodyReceipt rather than a second local admission receipt.

### O3. Mandatory append transaction

```text
append(request):
  1 lock idempotency binding
  2 lock all ShardHead rows sorted by canonical shard key
  3 lock all stream_head rows sorted by canonical stream key
  4 recheck writer, policy, registry, and shard-map epochs
  5 require expected stream sequence; allocate next stream sequence
  6 allocate next commitSequence by transactional ShardHead increment
  7 validate exact record/proof/request digests and authorization
  8 build receipt using locked lastReceiptDigest
  9 insert record, receipt, exactly one canonical admission event, and outbox row
 10 advance stream and shard heads; commit
```

If the transaction rolls back, neither head advances and no commitSequence is consumed. Concurrent writes to one logical shard serialize on ShardHead. Multi-shard transactions lock in canonical key order and either commit all shard prefixes or none.

### O4. Exact request digest and idempotency resolution

```text
RequestDigestInput {
  profile, operationFamily, tenantId, streamId,
  expectedStreamSequence, writerEpoch, requestedPurpose,
  contentType, recordDigest, contentDigest,
  detachedProofSetDigest
}

requestDigest = SHA256(
  "RTRACER\0REQUEST\0v1.4\0" || JCS(RequestDigestInput)
)

detachedProofSetDigest input order:
  sort proof references by proofId then proofDigest

POST /v1/idempotency:resolve
{ operationFamily, idempotencyKey }
```

Resolution is authenticated and scoped to current tenant and principal. It returns the original authorized receipt/state or a non-leaking absent response. A retry that changes any digest input is equivocation. A client with an unknown network result resolves the original key before creating a new intended operation.

### O5. Canonical admission event and publisher

```text
CanonicalAdmissionEventV1_4 {
  profile, eventId, eventKind: "ledger.record-admitted.v1",
  ledgerId, tenantId, logicalShardId, chainEpoch, commitSequence,
  streamId, streamSequence, recordId, recordDigest,
  receiptId, receiptDigest, correlationId?, causationId?,
  recordedAt, eventDataDigest
}

brokerPartitionKey = tenantId || logicalShardId || chainEpoch
```

One admitted record produces exactly one canonical admission event. A fenced publisher emits commitSequence in order within the broker partition and preserves event ID and canonical bytes on every retry. CloudEvents attributes duplicate routing fields for transport only; disagreement with canonical EventData quarantines the envelope. Derived topics may partition by semantic stream but MUST NOT advance canonical shard checkpoints.

### O6. Projection checkpoint, cross-shard fold, and replay

```text
ProjectionCheckpointV1_4 {
  profile, projectionId, projectionVersion, codeDigest,
  registryCheckpoint, policyBundleDigest, orderingMode,
  ledgerId, tenantId, logicalShardId, chainEpoch,
  inclusiveCommitSequence, terminalReceiptDigest,
  stateDigest, generation, priorCheckpointDigest?,
  status: ACTIVE|DEGRADED|NON_REPRODUCIBLE_BY_POLICY|FAILED
}
```

Consumer deduplication, projection mutation, and checkpoint advance commit atomically. A checkpoint advances only over a contiguous applied prefix. A checkpoint vector is compared componentwise and is never collapsed into a scalar.

Cross-shard projectors declare one of three contracts: independent per-shard fold plus deterministic reduction; associative/commutative merge; or a canonical computational fold explicitly carrying no chronological meaning. They MUST NOT invent cross-shard wall-clock order from receipt time, UUID locality, or broker arrival.

Recovery has two valid modes: restore a state snapshot with its exact checkpoint, or start from empty state with genesis checkpoints and replay the complete required prefix. Erased inputs produce typed ReplayTombstone and ErasureReceipt records. A view needing destroyed bytes is NON_REPRODUCIBLE_BY_POLICY, not verified or silently incomplete.

### O7. Confidential query cursor

```text
CursorBindingV1_4 {
  cursorProfile, queryDigest, requestingPrincipalId?, audienceClass,
  purpose, checkpointVector, projectionDescriptorDigest,
  codeDigest, registryCheckpoint, policyBundleDigest,
  sortPosition, expiresAt, keyEpoch
}
```

The client receives authenticated encryption of this binding or an opaque random server-side handle. Plaintext tokens are prohibited. A cursor is rejected when principal/audience, purpose, query, projection generation, code, registry, policy, checkpoint scope, expiry, or key epoch changes. Private sort tuples and tenant identifiers are not readable by the client.

### O8. Authority clock, lease, command, and disposition

```text
AuthorityClockRef {
  arbiterId, clockId, arbiterBootId, tickRate,
  authorityEpoch, antiRollbackStateDigest
}

ControlCommandV1_4 {
  profile, commandId, controllerId, controllerBootId,
  authorityClockRef, leaseId, authorityEpoch,
  commandSequence, sequencePolicy,
  functionId, targetSelector, setpointOrAction,
  frameRef, envelopeRef, issuedTick, expiresTick,
  commandDigest, controllerProofRef
}

CommandDispositionV1_4 {
  commandId, commandDigest, admissionResult, admissionReasonCodes[],
  admittedAtTick?, executionState, executionEvidenceRefs[],
  finalAtTick?, dispositionDigest, arbiterProofRef
}
```

Arbiter reboot changes arbiterBootId and increments a persisted authority epoch before arming. Anti-rollback failure latches SAFE. Exact duplicate ID/sequence/digest returns the original disposition without actuator re-entry. Same ID or sequence with different digest is equivocation and fences the controller. Lower sequence is stale. A gap follows the function’s STRICT_CONTIGUOUS or validated MONOTONIC_SUPERSEDING policy. Admission decision and physical execution outcome remain separate.

### O9. Atomic external action dispatch

```text
ActionDispatchEnvelopeV1_4 {
  profile, actionId, proposalDigest, policyDecisionDigest,
  confirmationDigest, budgetReservationDigest,
  connectorManifestDigest, renderedProviderRequestDigest,
  oneTimeDispatchNonce, dispatchEpoch, expiresAt,
  envelopeDigest, brokerProofRef
}

dispatch transaction:
  require current grants, policy, confirmation, reservation, connector, epoch
  require nonce unconsumed and envelope exact
  consume nonce and append DISPATCHING atomically
  commit before provider network I/O
  reconcile provider effect to SETTLED, PROVEN_NOT_EFFECTED,
    UNKNOWN_EFFECT, COMPENSATING, or OPERATOR_REQUIRED
```

Two workers can never both consume one nonce. Provider timeout is not failure. Vehicle persona, content, and social runtimes do not possess the R5 action type; denial is structural before policy.

### O10. Merkle checkpoint construction

```text
leaf = SHA256("RTRACER\0MERKLE-LEAF\0v1.4\0" ||
              uint64_be(commitSequence) || receiptDigest)

node = SHA256("RTRACER\0MERKLE-NODE\0v1.4\0" || left || right)

odd level rule:
  promote the final unpaired node unchanged with a domain-separated
  level/width commitment in the checkpoint; do not duplicate it

LedgerCheckpointV1_4 {
  profile, ledgerId, tenantId, logicalShardId, chainEpoch,
  firstCommitSequence, lastCommitSequence, leafCount,
  merkleConstructionProfile, merkleRoot, terminalReceiptDigest,
  priorCheckpointDigest?, createdAt, signerKeyEpoch,
  backupSnapshotRefs[], checkpointDigest, proofRef
}
```

Golden fixtures include odd/even leaf counts, inclusion paths, prefix consistency, epoch bridge, and corrupted-leaf rejection. Implementations cannot choose their own odd-leaf convention.

# Appendix P. Exact documentation release bundle and agent-discovery contracts

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.appendix.p · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:155cf97c44f96d00496219d6140a5e470229210ff9e8c3b54a8805128a89ef14

### P1. Route topology

| Route | Contract |
| --- | --- |
| /substrate/ | living human landing and current-release discovery |
| /substrate/versions.json | release catalog with exact targets |
| /substrate/identity-index.json | stable ID to exact route per release |
| /substrate/v1.4.0/ | immutable canonical release landing |
| /substrate/v1.4/ | mutable edition alias to newest 1.4 patch |
| /substrate/latest/ | mutable alias to latest stable release |
| /substrate/v1.4.0/reference/{registeredRoute}/ | immutable canonical human section |
| matching section.md and section.json | immutable canonical machine section |
| /substrate/v1.4.0/manifest.json | exact exhaustive release manifest |
| /substrate/v1.4.0/migrations/from-v1.3.0.json | cross-release migration map |
| /substrate/v1.4.0/changes.json | machine-readable changelog |
| /substrate/v1.4.0/deprecations.json | lifecycle registry |

Established unversioned v1.3 section URLs remain resolvable and identify their legacy status. They do not silently become aliases to edited v1.4 content.

### P2. Release catalog and discovery

```text
ReleaseCatalog {
  schema, projectId, latestStableRelease, latestEditionAliases,
  releases[{ edition, releaseVersion, schemaVersion, status,
             canonicalBase, manifestUrl, manifestSha256,
             sourceSha256, compatibility, publishedAt }],
  credit, watermark
}

DocumentationDiscovery {
  schema, projectId, humanEntry, versionsUrl,
  latestStableManifest, identityIndexUrl,
  agentInstructionsUrl, credit, watermark
}
```

### P3. Exact release manifest

```text
ReleaseManifest {
  schema, projectId, edition, releaseVersion, schemaVersion,
  status, canonicalBase, language, title, credit, watermark,
  source{ filename, sha256, creator }, generatedAt,
  profiles{}, compatibility{}, supersededClauses[],
  migrationRefs[], changeRef, deprecationRef,
  stats{}, sections[], fixtures[], schemas[],
  artifacts[{ path, mediaType, byteLength, sha256 }],
  releaseGate{ status, checks[], twoImplementationProof? }
}
```

Artifact entries exclude the manifest and manifest.sha256. The manifest is serialized deterministically and manifest.sha256 covers its exact bytes. An optional detached signature signs the exact manifest bytes. Accepted exact releases refuse overwrite unless verification mode proves every byte equal.

### P4. Semantic and artifact digests

```text
semanticDigest = SHA256(JCS({
  schemaVersion, stableId, title, normativeStatus, blocks
}))

artifactSha256 = SHA256(exact_published_bytes)
```

The semantic digest changes when normative content or stable meaning changes. The artifact digest changes for any byte-level representation change. Build timestamp, absolute source path, and local environment never enter semantic identity.

### P5. Section identity and migration entry

```text
SectionIdentityEntry {
  stableId, registeredRoute, title,
  headingIds[], requirementIds[], fixtureIds[],
  firstRelease, lifecycleStatus, replacementIds[]
}

MigrationEntry {
  priorStableId, currentStableIds[], classification,
  priorTitle, currentTitles[], priorUrls[], currentUrls[],
  priorSemanticDigest, currentSemanticDigests[],
  compatibilityImpact, affectedFixtureIds[], explanation
}
```

classification is unchanged, modified, renamed, moved, split, merged, deprecated, or removed. Added records are listed with firstRelease. An unchanged classification requires equal semantic digests.

### P6. Build and acceptance sequence

Build all exact release artifacts in a new staging directory. 2. Validate source credit/watermark, stable identities, fixture uniqueness, schemas, cross-links, and canonical routes. 3. Hash every artifact and write the exhaustive manifest. 4. Hash and optionally sign the exact manifest bytes. 5. Rebuild from a clean directory and prove byte-identical output. 6. Atomically promote the exact release directory. 7. Update mutable catalog/aliases only after exact release validation. 8. Package the same bytes into preview and the active application; never regenerate independently.

# Appendix Q. Thirty-two corrective runtime and release conformance fixtures

> Created and directed by LNK. © LNK. All rights reserved.
> Watermark: LNK // RTRACER // AUTHORITATIVE DOCUMENTATION CORPUS
> Stable ID: rtracer.appendix.q · Edition: 1.4 · Normative release: 1.4.0 · Presentation bundle: 1.4.1 · Semantic digest: sha256:17d3e6e1403cda865662c99e2b64a153e7b87aee45a0ff24d085971b9024db54

These fixture IDs continue after Appendix M. Exact fixture bundles provide setup records, canonical input bytes, keys where safe, policy/registry locks, expected codes, output bytes/digests, SQL state, event sequence, and projection state.

### Q1. Ledger, receipt, event, and idempotency

| ID | Scenario | Expected code or result |
| --- | --- | --- |
| T-297 | Two streams append concurrently to one logical shard. | One gap-free commitSequence and one contiguous receipt chain. |
| T-298 | Transaction rolls back after provisional commit-sequence computation. | ShardHead does not advance; no committed gap. |
| T-299 | Lower commit remains open while a higher append races. | Higher append waits on ShardHead. |
| T-300 | Publisher crashes after broker acknowledgement. | Same event ID/bytes redelivered; consumer applies once. |
| T-301 | Consumer receives noncontiguous commitSequence. | Halt with RTR-EVENT-COMMIT-GAP. |
| T-302 | Logical shard handoff lacks signed bridge. | Reject with RTR-LEDGER-SHARD-HANDOFF. |
| T-303 | Retry changes expected sequence only. | Idempotency equivocation. |
| T-304 | Retry changes detached proof set only. | Idempotency equivocation. |
| T-305 | Unknown-result resolution occurs under another principal. | Non-leaking denial. |
| T-306 | Same record ID/digest is submitted under another key and stream. | Placement conflict; no second append. |

### Q2. Proof, checkpoint, cursor, and replay

| ID | Scenario | Expected code or result |
| --- | --- | --- |
| T-307 | Proof signer field changes without resigning. | RTR-PROOF-TARGET-MISMATCH. |
| T-308 | Proof creation time or key epoch changes. | Invalid proof. |
| T-309 | COSE protected algorithm disagrees with ProofTarget. | RTR-PROOF-ALGORITHM-CONFUSION. |
| T-310 | Receipt store identity changes after proof. | Invalid store proof. |
| T-311 | Merkle implementation duplicates odd leaf. | Golden-root mismatch. |
| T-312 | CloudEvents shard/sequence differs from canonical event. | Quarantine envelope. |
| T-313 | Cursor plaintext exposes a private sort value. | Privacy conformance failure. |
| T-314 | Cursor crosses projection code generation. | Reject and restart query. |
| T-315 | Cross-shard deliveries are permuted. | Same declared deterministic reduction digest. |
| T-316 | Empty projection starts from restored nonzero checkpoint. | Recovery blocked. |
| T-317 | Replay encounters lawful erasure tombstone. | Qualified NON_REPRODUCIBLE_BY_POLICY result. |
| T-318 | Legacy ledger is sealed and bridged. | First v1.4 receipt verifies bridge. |
| T-319 | Legacy receipt chain fails pre-cutover audit. | Migration blocked; incident opened. |

### Q3. Control, dispatch, and executable release proof

| ID | Scenario | Expected code or result |
| --- | --- | --- |
| T-320 | Lease clock ID matches but arbiter boot ID differs. | Reject before actuator. |
| T-321 | Persisted authority epoch rolls backward after reboot. | Latch SAFE. |
| T-322 | Exact command duplicate arrives twice. | One actuator application; original disposition returned. |
| T-323 | Same command sequence carries a different setpoint. | Equivocation; fence controller. |
| T-324 | Command sequence gap occurs under STRICT_CONTIGUOUS policy. | Reject and invoke fallback. |
| T-325 | Command is admitted but feedback times out. | Admission retained; execution UNKNOWN_FEEDBACK. |
| T-326 | Two workers consume one dispatch nonce. | Exactly one enters DISPATCHING. |
| T-327 | Social-agent runtime submits an R5 action. | Action type is structurally unavailable. |
| T-328 | Fixture manifest omits input or golden artifact. | Release gate fails. |

Existing fixtures T-010, T-057, T-058, T-234, T-243, and T-253 are interpreted under the v1.4 proof target, commit sequence, shard head, confidential cursor, and replay rules when a v1.4 profile is declared.