Platform

The same loop, pointed at a machine instead of a repository.

Credda is one company with one loop: observe, understand, plan, act, verify, learn. What it sells in every environment is that an autonomous system’s action is never taken on its word. The system states what the action is expected to cause before it acts, and afterwards the claim is settled by evidence.

Software is the first environment and it is the product you can use today. Everything on the rest of this page is the second one. It is in development and it is entirely simulated: no robot, PLC, MES, sensor, camera or plant is connected, and no model has been trained. Every figure below comes from a deterministic simulation and is labelled SIMULATED. The software product installs here.

01The loop

Observe, understand, plan, act, verify, learn.

The abstraction is not quality assurance in the old sense. It is verified autonomous intervention, and the same six steps run whether the thing being changed is a repository or a cell.

Observe: Events arrive from the environment and are appended to a hash-chained log. Nothing else is a source of truth.
Understand: Entity state at any instant is a pure fold over that log, so a question about the past is answered from the record rather than from memory.
Plan: Candidate interventions are forecast on a fork of the twin, each with the metrics it is expected to produce.
Act: Every command is sealed before the environment sees it. There is no other path to an environment.
Verify: The expectations stated before the action are judged from the events that followed, by a reader that is not the agent that acted.
Learn: The run is complete by construction, which is what replay and training data need. No training has been run.

Read from credda/platform/docs/architecture.md. On the software side the same loop is a reproduction, a diagnosis, a patch and a test that fails before and passes after. What a software run produces.

02The layers

One interface between the intelligence and the environment.

Each layer depends only on the ones below it and on the contracts. The move toward hardware is a new adapter behind that one interface rather than a rewrite above it, which is the property the whole stack is arranged to have.

credda/platform/README.mdthe package table, copied

The packages of the Credda platform, the layer each one is, and what it holds.
Package	Layer	What it is
packages/schemas	vocabulary	Versioned contracts: entities, events, commands, actions, expectations, verification, autonomy levels, run manifest.
packages/events	record	An append-only, hash-chained event log.
packages/world-model	world model	Temporal entity state as a pure fold over the log.
packages/environment-sdk	environment	The one interface between intelligence and an environment, simulated or real.
packages/control	action and control	A run session that seals every command before it executes, and the cell dispatcher.
packages/agents	intelligence	Observer, early warnings, diagnostician, planner, simulation agent, executor, and the loop that sequences them. Deterministic and model-free.
packages/verification	verification	Expectations stated before an action and judged afterwards from sealed events only. No evidence is never a pass.
packages/safety	action and control	Constraint validation that fails closed, six explicit autonomy levels, human approval, and a gate that records every transition and issues no commands.
packages/recorder	record	Saved runs are refused on load if their chain does not hold. A run replays exactly against a fresh environment.
packages/evaluation	evaluation	Metrics from sealed events, diagnosis grading against ground truth that no agent may read, and deterministic synthetic runs.
packages/robot-sdk	action and control	A vendor-neutral robot handle and a fleet allocator. Path planning, collision avoidance and charging are interfaces only.
packages/telemetry	perception	REST and MQTT 3.1.1 connectors (subscribe only, QoS 0, no TLS, no reconnect), each tested against a local server or broker. OPC UA, Modbus, SQL and camera connectors throw.
packages/dataset	evaluation	Many seeded runs as data: examples, the measurements they are judged against, sharded JSONL under a manifest that commits to every byte, and a reader that refuses a tampered corpus. Nothing here trains anything, and every example it can produce today came from a simulated environment and says so.
packages/model-sdk	intelligence	Model roles with attribution on every call. The only model is a statistical baseline, and no external provider adapter is written.
packages/software-environment	environment	REAL. A repository under the Credda engine, behind the same environment interface, with the loop that gates each finding by autonomy level before the engine investigates it. Model-free by construction, and it cannot open a pull request.
simulations/manufacturing-cell	environment	SIMULATED. A deterministic, seeded, forkable cell with causal faults (bearing friction, coolant loss, infeed jam, gripper slip) and sensor, ambient and takt disturbances.

Every row is a directory in that repository. A layer named without its module is a diagram.

The agents are written against that interface and against the world model, so they cannot tell a simulation from hardware and cannot read the simulator’s injected faults. The twin stops being an exact copy the day a real adapter sits behind the interface, and the gap between a forecast and a verified outcome becomes a measured quantity. No such adapter exists.

03Autonomy

Accepted is not executed is not verified.

Three facts, established by three different parties, and no type lets one stand in for another. Collapsing them into one word is how an autonomous system ends up believed.

Accepted: The environment issued a receipt for a sealed command. It says the command was taken, and nothing about what it did.
Executed: The environment’s own later events report the action finished. Finished is not the same as worked.
Verified: A verifier read the sealed events inside the verification window and judged the expectations that were stated before the action. This is the only one of the three that is a claim about the outcome.

Six levels, named in the contracts rather than configured in prose

A run declares the level it is operating at and the level is recorded in its manifest. The run below is level 3, so every action was put to an approver before it was authorised.

credda/platform/packages/schemas/src/index.tsAUTONOMY_LEVELS

The six autonomy levels a Credda platform run can declare.
Level	Name
0	OBSERVE_ONLY
1	RECOMMEND
2	SIMULATE
3	HUMAN_APPROVAL_REQUIRED
4	BOUNDED_AUTONOMOUS
5	HIGHLY_AUTONOMOUS

Read out of the contract, not written for this page.

Nothing happens off the record: the only path to an environment seals the command first, and the only path to the world model is the log. A run is therefore complete by construction, which is what replay needs.

04One run, SIMULATED

A hidden fault at 5.0 min, and a verdict at 24.0 min.

One recorded run of the simulated cell: a conveyor, a robot arm, two machines and an inspection station, with a causal thermal failure model. Seed 7, 9,179 events, every one of them hash chained and marked SIMULATED.

5.0 min · SIMULATED: A bearing-friction fault is injected on machine:cnc-a. It is hidden: it is never emitted as an event, and no agent can read it.
12.0 min · SIMULATED: The observer raises a throughput alarm. 108 good units per hour against a baseline of 144, a drop of 25 percent, from the sampled window between 7.0 and 12.0 min.
12.0 min · SIMULATED: The diagnostician names machine:cnc-a and abnormal heat, with three of three evidence checks holding: mean motor temperature 48.0C to 75.8C; cycle time 12.0s to 14.7s; and the temperature leaving its baseline at 337.0s, before the cycle stretched at 488.6s.
12.0 min · SIMULATED: Four interventions are forecast on a fork of the twin over a 30 minute horizon. Reducing the load forecasts worse than doing nothing. The table below is that forecast.
12.0 min · SIMULATED: Two actions are approved and executed: route production to machine:cnc-b, then start maintenance on machine:cnc-a.
14.0 min · SIMULATED: The third action is approved and executed: route production back to machine:cnc-a. It is the one that carries expectations, and the verification window opens here.
24.0 min · SIMULATED: The verifier reads the sealed events of that window and returns PASSED on all six expectations. The table below is that verdict.

demo-L3-seed7 · forecastSIMULATED · 30 minute horizon, on a fork of the twin

The four interventions forecast in the simulated run, with the good units and defect share each was forecast to produce.
Intervention	What it does	Good units	Defect share
maintain-and-return	Run on machine:cnc-b while machine:cnc-a is maintained, then return	70	0.08
switch-production	Switch production to machine:cnc-b	61	0.09
do-nothing	Leave the cell as it is	50	0.10
reduce-load	Reduce machine:cnc-a load to 70 percent	44	0.06

Reducing the load forecasts 44 good units against 50 for leaving the cell alone. A lower load lengthens the cycle faster than it sheds heat, and the system reports that rather than hiding it behind a ranking.

demo-L3-seed7 · verificationSIMULATED · window 14.0 min to 24.0 min · PASSED

The six expectations stated before the final action, what each required, and what the sealed events showed.
Expectation	Stated before the action	Observed
machine:cnc-a:thermal-limit	max motorTempC < 90	40.11
machine:cnc-b:thermal-limit	max motorTempC < 90	39.93
throughput	>= 129.6 accepted parts per hour	144
production-rate	>= 144 parts cut, before inspection	150
beats-doing-nothing	> 96 accepted parts per hour, the forecast for doing nothing	144
defect-share	<= 0.2174 rejected share	0.04

Each expectation was sealed with the action, before it ran. The verifier reads the events of the window and never asks the agent that acted.

The approver in that run was a script, and the run records it as one. The manifest names the approver operator:scripted-demo (a script, not a person). Level 3 means a human approval step exists and was exercised by a stand-in. No person approved anything, because there was nothing physical to approve.

05What is real today, and what is not

The part of this page to read first.

Copied from the status table the platform repository keeps on itself. Nothing here is rounded up, and the absences are in the same section as the things that exist.

credda/platform/docs/architecture.mdthe status table, copied

What exists in the Credda platform today and the status of each part.
Part	Status
Contracts, event log, world model, environment interface	Implemented and tested
The manufacturing cell	Implemented, SIMULATED. Not a model of any real plant
Observer, diagnostician, planner, simulation agent, executor	Implemented, deterministic, model-free
Verification, safety gate, six autonomy levels, human approval	Implemented, tested at every level
Run recording, exact replay, evaluation, diagnosis grading, synthetic runs	Implemented and tested. A saved run replays exactly against a fresh environment
A repository under the Credda engine, as an environment	Implemented, REAL, model-free. The one environment here that is not simulated
The loop over a repository, gated by autonomy level	Implemented, REAL. Each finding is gated, and at level 3 a named person approves it, before the engine investigates. Level 4 refuses: bounded autonomy needs a forecast, and a repository has no twin
Telemetry connectors	REST (HTTP GET, JSON) and MQTT 3.1.1 (subscribe only, QoS 0, no TLS, no reconnect) work, each tested against a local server or broker. OPC UA, Modbus, SQL and camera are stubs that throw
Robot handle, fleet allocator, model roles	Implemented. Path planning, collision avoidance and charging are interfaces only, and the only model is a statistical baseline

Implemented means the code exists and the tests run. It does not mean it has met hardware.

And what does not exist

Each line below is an absence rather than a control. A reader who stops here should stop with these.

No robot, PLC, MES, sensor, camera or plant is connected. None exists here.
No connector has ever been pointed at real equipment. OPC UA, Modbus, SQL and camera are stubs that throw.
No trained or proprietary model. The data structures for training exist and no training has run.
No customer and no pilot in manufacturing or robotics.
No real-time guarantee and no safety certification of any kind.
No price, no availability and no date. None of this is for sale.

The product that exists is the software one, measured in public on repositories we did not choose. The benchmark, every case, and what an install involves.