PULSE makes the knowledge graph executable, but not a source of truth

PULSE offers a solution to one of the vexing problems of knowledge graph engineering: the rules governing what can be recorded, modified, and considered proven often exist separately from the data itself. As a result, the graph formally describes a state, while the actual contract for its execution must be reconstructed from code, diagrams, and agreements between systems.

PULSE brings these operational roles and recording effects together into a single, typed runtime. This is not a new modal logic or a deontic system: here, “modes” specifically refer to operating modes. The language specifies how to handle evidence, states, constraints, processes, and hypothetical branches.

The most useful part of the idea is not the syntax, but the constraints that become enforceable. In a verified PULSE fragment:

• it does not allow evidence to be overwritten;
• it isolates scenario branches;
• it supports timers bound to multiple entities;
• it requires safeguard conditions for state changes;
• it defines the order of events in time and space through the priority of declarations.

This is a significant shift compared to a graph that merely stores facts. The contract can now not only describe a valid state but also restrict the ways in which the system reaches it.

But PULSE does not automatically resolve the issue of trust. An external runner still determines whether evidence becomes an authoritative move. In other words, the language is capable of maintaining execution boundaries, but it is not itself responsible for the policy or engineering decision: whether a specific observation is sufficient to change the official state.

The authors tested not an abstract idea, but a specific implementation fragment: 88 tests, 3,534 limited checks, and 32 cases comparing Lean 4 with the Python core. In Lean, analogues of mechanisms for positions, evidence, clocks, monitors, and atomicity were tested. Separate implementations based on standards composition and Sismic statecharts reproduced the test cold-chain trace.

On 37,440 generated time traces, PULSE matched a specific workflow and distinguished ten mutants that each changed a single field. On the complete subset of NOAA IBTrACS data from 1980 onward, the system matched GEOS and the event sweep for 1,476,290 pairs in the transition zone; separately, 4,800 selected events and 12,831 events that passed the duration check were accounted for.

These figures support a narrower claim than the abstract might suggest: contract-based localization, safety arguments, and track matching work on the verified dataset. They do not prove the language’s superiority or its convenience for developers—the authors explicitly exclude usability from their evaluation.

The practical conclusion is simple: PULSE should be viewed not as a replacement for GeoSPARQL, SOSA, or SHACL, but as an executable layer built on top of them. These standards remain generated representations, whereas PULSE attempts to fix the order of operations and the effects of a write operation. For systems where an error in a state transition is more dangerous than an incomplete graph, such a layer may be more useful than yet another declarative schema. However, the source of truth will still need to be defined outside the language.

Source: cs.AI updates on arXiv.org