LDTC¶
LDTC (Loop-Dominance Theory of Consciousness) is a single-machine, real-time verification harness for the theory of the same name. It is the reference implementation that accompanies the LDTC manuscript and is designed to either falsify or accept the two operational criteria from that paper:
| Criterion | Plain English | Pass when |
|---|---|---|
| NC1 | The closed loop dominates exchange with the environment. | M (dB) ≥ Mmin window-by-window. |
| SC1 | The loop's M survives a labeled Ω perturbation and recovers fast enough. |
δ ≤ ε and τ_rec ≤ τ_max after the Ω window. |
The harness measures loop and exchange influence (𝓛_loop, 𝓛_ex)
at a fixed Δt, applies guardrails (LREG enclave, hash-chained
audit, Δt governance, smell tests), runs Ω perturbations from
ldtc.omega, and emits device-signed derived
indicators, never raw 𝓛. Everything else (figures, tables,
manifests) is generated from the audit log alone, so you can publish
artifacts without leaking measurement primitives.
What this is, and isn't
LDTC is a verification harness, not a model of mind. It
answers a narrow, falsifiable question: "Does this concrete
system, instrumented at this Δt, pass NC1 and SC1 against
Ω?" It does not claim consciousness; it gives you a tool to
check whether the loop-dominance signature holds.
Try it in 60 seconds¶
The smallest end-to-end run uses the bundled R0 profile and the in-process software plant:
That command will:
- Boot a fixed-
Δtscheduler and a small software plant (ldtc.plant.models.Plant). - Stream
(E, T, R, demand, io, H)telemetry into aSlidingWindow. - Per window, estimate
𝓛_loopand𝓛_exviaestimate_Land computeM (dB)viam_db. - Append every event to an append-only, hash-chained audit log
(
AuditLog). - Sign and write derived indicators (NC1 bit, SC1 bit,
Mq, counter) viaIndicatorExporter. - Build a paper-style timeline, an SC1 table, and a manifest via
reporting.artifacts.bundle.
Then exercise the Ω battery:
The command applies a labeled power sag, freezes the C/Ex partition during the perturbation, and writes a fresh signed indicator with the SC1 bit decided.
Walk through the full setup in Getting started, or skip ahead to the Examples.
Why LDTC¶
- Operational, not metaphysical. NC1 and SC1 are concrete
inequalities on
M (dB),δ, andτ_rec. There is nothing to argue about in the result; either the indicators pass or they don't. - Quietly tuning the result is hard on purpose.
Δtchanges are rate-limited and audited (DeltaTGuard); CI inflation, partition flapping duringΩ, exogenous subsidy, and audit-chain breaks each invalidate a run viasmelltests. - No raw
𝓛ever leaves the box. TheLREGis a write-only enclave; exporters and CSV writers refuse rows that contain raw fields. Only the device-signedIndicatorpayload escapes. - Substrate-agnostic. Both
PlantAdapter(in-process software model) andHardwarePlantAdapter(UDP / serial) satisfy the same minimal interface, so the sameΩmodules work against simulation and real hardware. - Reproducible artifacts. Every produced file is
chmod-ed read-only on POSIX-like systems, and every figure carries a footer with the profile (R0/R*) and the audit hash head.
Documentation map¶
- Get started: install the package, run R0, and read the first artifact bundle in Getting started.
- Concepts: start with the mental model, then read definitions, architecture, indicators, guardrails, and the paper-to-code crosswalk.
- Guides: task-oriented recipes for running the harness, calibrating an R* profile, reporting, hardware in the loop, and deployment.
- Examples: the minimal example and Jupyter notebooks.
- API reference: auto-generated, one page per subpackage. Start
with
ldtcfor the package overview. - Meta: contributing, documentation style guide, FAQ, troubleshooting, and citation.
Next steps¶
- New here? Read Getting started and then Mental model.
- Coming from the paper? Jump straight to the paper-to-code crosswalk.
- Deploying on real hardware? See Hardware in the
loop and
HardwarePlantAdapter. - Looking for an API symbol? Use the search box at the top of the
page or browse the
ldtcAPI reference.