Designing DPSH applications

DPSH is intended for living machines in a technical sense: autonomous systems that continuously perceive, maintain their own dynamic state, act, observe the consequences of their actions, and adapt again. This is not a claim that a machine is biologically alive or conscious. “Living” here means that control is not a one-shot input → response calculation, but a closed temporal loop: body → environment → body.

Under present hardware constraints, the most natural target class is a small autonomous robot: a rover, simple manipulator, floating or flying platform, interactive sensory head, or laboratory apparatus. Such a machine has a limited number of sensors and actuators, relatively slow mechanics, and dynamics rich enough to study prediction, attention, reversals, adaptation, and multimodal integration.

What DPSH is for

DPSH is neither a general replacement for classical control nor a universal robotics framework. It is useful when internal dynamics are themselves the subject of design or experiment:

  • how a system combines multiple sensory modalities into a shared state;
  • how it chooses among several simultaneously possible actions without a central argmax;
  • how expectation and efference copy alter the response to actual sensory feedback;
  • how oscillator phase prepares the network for a percept or action;
  • how it returns to a regime, transitions into another regime, or fails after a perturbation;
  • how plasticity changes the closed loop over time;
  • whether observed behavior survives ablation, a matched control, and replay.

Conversely, DPSH should not be entrusted on its own with emergency stopping, current limits, battery protection, fast flight-axis stabilization, or another safety-critical function. Those tasks belong in a simple, auditable controller close to the hardware.

Basic architecture of a living machine

               ┌────────── safety envelope ──────────┐
               │ limits, watchdog, E-stop, fallback  │
               │                                      │
environment → sensors → timed modalities → DPSH → population actuators
    ↑                                      │              │
    └──────────── mechanics and body ←──────┴──────────────┘
                         │
                  trace + recorder
                         │
                replay + matched controls

The safety envelope has the final say. DPSH proposes a continuous intent, for example left_wheel = 0.42, but the hardware layer decides whether the command is admissible, limits its rate of change, and enters a safe state when the heartbeat is lost.

Design kit: the design process

1. Start with the body, not the network

Write down the physical contract first:

Area Questions
sensors What is actually measured? What are its range, noise, and failure modes?
transport What are the latency, jitter, frequency, and packet ordering?
actuators What continuous command do they accept, and how quickly does it take effect?
mechanics What are the inertia, dead zones, and saturation points?
safety Which limits must the neural network never exceed?
time Which processes occur in µs, ms, tens of ms, and seconds?

A modality delay in Cognia should represent measured transport and preprocessing, not a number selected merely to make the model look stable.

2. Choose a small behavioral problem

The first DPSH application should have one closed loop and an outcome that can be observed without interpretation. Good initial tasks include:

  • maintaining heading and reacting to a blocked wheel;
  • choosing a passage between two similar obstacles;
  • turning a sensory head toward a source of sound or motion;
  • switching between exploration and return to a charging point;
  • simple manipulation with measurable contact or slip.

Start with 50–500 neurons, from a few to a few dozen named channels, and several antagonistic output populations. A small model is easier to explain, replay, and ablate. A larger network is not inherently more alive.

3. Name every modality by its physical meaning

A channel should not be an anonymous input index. It should have a name, unit, expected range, gain, transport delay, and clear target population. External sensory input and internal spike input follow the same path; a special “smart” shortcut into neuron state would violate the causal model.

Before injection, normalize physical values with a stable, versioned mapping. Record both the original value and the value injected into the network in the trace.

4. Encode action with a population

Design a motor output as the difference between two populations:

command = gain × (pro_activity − opposing_activity)

For a left wheel, for example, populations left_forward and left_reverse may inhibit each other. Zero is an equilibrium between two measurable tendencies, not necessarily silence. The output is more robust to a single neuron and preserves information about ambivalence. Do not reintroduce argmax through the back door of motor decoding.

The motor sink is a read-only observer of a committed window. Attaching a real motor must preserve invariant I-9: the event log with the sink attached is bit-identical to a run without it.

5. Model efference copy as an ordinary causal path

The predicted consequence of an action should not be a privileged global signal. Route a copy from the motor population to a local prediction population through an explicit synaptic delay. The real encoder or other proprioceptive feedback arrives through its own modality.

The difference between expected and actual feedback may then mean slip, contact, lifting the robot, or a drive fault. The first experiment should not require learning: verify that prediction error responds in a fixed network, and compare it with ablation of the prediction path over the same recorded trace.

6. Build competition as topology

Represent possible actions or percepts with populations that have local recurrent excitation and lateral inhibition. Inhibition should not be so strong that it creates absolute winner-take-all behavior. The suppressed alternative must remain measurable; its survival is what permits ambivalence and spontaneous reversals.

Neither a workspace nor a controller should perform hidden winner selection. An observer may measure ignition, dominance, and reversal, but must not write them into the network.

7. Derive time constants from the closed loop

At minimum, the model must distinguish these scales:

  • sensor and actuator transport;
  • minimum synaptic delay d_min;
  • neuron membrane and adaptation time;
  • refractory interval;
  • oscillator period;
  • motor decoding-window length;
  • mechanical response of the body;
  • learning and homeostatic scales.

Do not try to unify every value under one main-loop frequency. DPSH exists precisely so that different processes can unfold in one exact model time without a global tick.

8. Separate model time from wall-clock time

Use Free for development, replay, and sweeps; use Paced for a living machine. If a paced run falls behind, that is a measured overrun. The runtime must not skip model windows or silently “catch up,” because timestamps would cease to describe the physics actually executed.

Profile these quantities separately:

  • packet-receive latency;
  • sample age at injection;
  • window computation time;
  • deadline overrun;
  • latency of sending and applying a motor command;
  • transport drops and reordering.

9. Replay first, autonomy second

Before the robot is allowed to act autonomously, it must pass gate R0:

logHash(live run over trace) == logHash(offline replay of the same trace)

The check must be sensitive: moving a single injection by 1 ns must break the hash. Only then is it meaningful to compare intervention and control branches, because the transport recording has been shown to reproduce the cause of the run.

10. Give every claim a control branch

A minimal experimental set for a mechanism includes:

  1. a baseline over a recorded trace;
  2. an intervention or enabled mechanism;
  3. a matched control preserving the relevant statistic;
  4. ablation of the mechanism;
  5. several seeds or frozen randomness, depending on the question;
  6. a predeclared metric and tolerance;
  7. the possibility of an inconclusive result.

For example, the effect of theta modulation must not be compared with a run having a different mean frequency. Phase scrambling must preserve frequency and amplitude. A prediction effect must not be confused with different RNG exhaustion.

Recommended application layers

device firmware
  └─ hard realtime, encoders, PWM, current limits, E-stop

device relay
  └─ monotonic timestamp, sequence, watchdog, packet protocol

host transport adapter
  └─ wire fields ↔ named Cognia modalities/actuators

DPSH runtime
  └─ causal dynamics, prediction, competition, plasticity

observer and experiment layer
  └─ trace, recorder, metrics, branches, report

A generic engine must know neither “left wheel,” a particular IMU type, nor a robot brand. Those concepts belong in the model and the application's transport adapter. The engine knows only named modalities, neurons, edges, actuators, and model time.

Safety kit for a small robot

DPSH is an experimental layer and must run inside a safety envelope. A practical minimum is:

  • a physical E-stop independent of the host process;
  • heartbeat and automatic stop on timeout;
  • hard firmware limits for speed, current, temperature, and joint range;
  • a slew-rate limit for motor commands;
  • validation of NaN, infinity, range, and age for every command;
  • sequence numbers and rejection of old or duplicate packets;
  • a safe state on restart, process crash, and network loss;
  • initial runs with wheels lifted or inside a bounded area;
  • separate logging of the DPSH command and the command actually applied by firmware;
  • no online plasticity during the first embodied tests.

The safety layer should not be neural and should not be subject to experimental ablation.

Staged commissioning

Phase A — pure simulation

  • verify parser, lowering, and capability checks;
  • verify CPU/CUDA parity and seed determinism;
  • measure responses to synthetic inputs;
  • check saturation, silence, and extreme hazard.

Phase B — hardware in the loop, without motion

  • receive real sensors;
  • log motor commands without applying them;
  • measure transport delay, jitter, and drops;
  • create the first trace and verify R0 replay.

Phase C — constrained actuators

  • lift the wheels or disconnect the mechanical load;
  • use a low hard limit and slew rate;
  • verify polarity, deadman timeout, and I-9;
  • compare intended and applied commands.

Phase D — closed loop without learning

  • fixed weights and a disabled learning gate;
  • one behavioral task;
  • baseline, ablation, and matched replay;
  • safe environment and a manual E-stop.

Phase E — exploratory adaptation

  • only after stable reproduction of R0–R4;
  • restricted edge groups and bounded weights;
  • a checkpoint before every series;
  • the ability to return immediately to a frozen baseline;
  • label results exploratory, including inconclusive outcomes.

Common design mistakes

  • Designing the network before measuring body latencies.
  • Connecting every sensor to every neuron “just in case.”
  • Using one neuron or argmax as output instead of antagonistic populations.
  • Using one global prediction-error scalar without local targets.
  • Allowing an observer, GUI, or motor sink to change network state.
  • Letting paced runtime skip time during an overrun.
  • Enabling online learning before a replay baseline exists.
  • Replacing an explanation of the mechanism with task success.
  • Presenting one seed or one attractive trajectory as evidence.
  • Letting a robot-specific protocol leak into the generic engine.

Minimal skeleton of a new project

my-dpsh-machine/
  model.cognia              substrate declaration
  transport-map.json        wire ↔ modality/actuator
  safety-contract.md        hard limits and failure modes
  timing-profile.md         measured latencies and jitter
  experiments/
    r0-replay.cognia
    baseline.cognia
    ablation.cognia
  traces/                    versioned input traces
  runs/                      registries and reports
  device-relay/              hardware-specific code

For every result, retain the model, engine version, theory version, config_hash, seed, trace, safety configuration, firmware version, and physical configuration of the machine.

Recommended first project

A small differential-drive rover is a good DPSH reference organism:

  • two motors naturally form antagonistic population outputs;
  • encoders provide efferent verification of actual motion;
  • camera, distance, IMU, and proprioception provide multiple modalities;
  • mechanics are slower than neural dynamics;
  • obstacles permit measurement of choice, ambivalence, and reversals;
  • a blocked wheel creates a clear local prediction error;
  • the hardware safety envelope is manageable.

After a rover, sensible next steps include a pan/tilt sensory head, a simple desktop manipulator, or a group of very small robots with limited communication. Moving to a fast drone, human-carrying vehicle, or powerful manipulator would require much stricter realtime, formal safety, and certification layers that DPSH 2.0.0 does not provide.

The design rule in one sentence

Design a DPSH application so that every input has a physical origin and time, every action has population meaning and a safety limit, every mechanism can be disabled, and every claim can be replayed, compared, and potentially falsified.