SignalQL v0.5 — object model
Status: Draft with reference implementation. Part of the v0.5 specification. See also provenance and context bundles.
Object
An object is any stable, addressable piece of information: a document, file, message, source file, video, image, dataset, conversation, AI output, meeting, or database record.
An object has an identity that is independent of where it is stored:
object://01JZX8…A path such as /projects/signalql/spec.md is metadata or a view. It MUST NOT define identity: moving or renaming an object does not change its address.
Object vs entity
| Is | Example | |
|---|---|---|
| OBJECT | a stored or addressable information artifact | q3-report.pdf |
| ENTITY | a semantic thing the information is about | Acme Corp, Project Phoenix |
Objects and entities are separate node classes in one graph. They are linked by ordinary edges (for example an object mentions an entity), so the v0.4 graph operators (MATCH, FIND … CONNECTED TO, PATH, TRACE, CONTEXT FOR) work across both without change. Only objects have revisions, representations, and derivations. Object ids and entity ids share one namespace.
Revision
A revision is one state of an object.
A revision changes state. It does not change identity.
object://abc@16 and object://abc@17 are two states of one object. Revisions are numbered from 1 and never renumbered.
Revision selection, with T the AS OF time (or unbounded when absent):
@nselects exactly revisionn. If it does not exist, or was created afterT, the result is empty.- Without
@n, the selected revision is the greatest revision created at or beforeT. If there is none, the object did not exist atT. - When both are given,
@nselects the revision andAS OFbounds everything else that is read.
superseded is a property of a revision (a later revision exists as of T). It is not a judgment about validity.
Origin, trust, validation, and roles describe a state of the object, so they are recorded per revision.
Representation
One object may exist in several forms:
OBJECT meeting_123
├── original-video
├── transcript
├── summary
├── decisions
└── embeddingsThese are representations of one object, not unrelated objects. A representation belongs to a specific revision, has a name unique within that revision, a media type, and optionally a token estimate with the name of the estimator that produced it.
A summary can be modelled either way. The rule: it is a representation unless it needs its own identity, history, or trust — in which case it is its own object linked by a derivation.
Logical sources
The reference compiler binds four logical sources through the source map. A deployment maps each to a physical table or view.
| Source | Columns |
|---|---|
objects | object_id, type, title, project, metadata (json), created_at, tombstoned_at |
object_revisions | object_id, rev, created_at, origin, trust, validation, roles (array), content_hash |
object_representations | object_id, rev, name, media_type, token_estimate, estimator, roles (array), content, content_ref, content_hash |
object_derivations | from_object, from_rev, relation, to_object, to_rev, created_at, metadata (json) |
project is an opaque partition label; the language attaches no meaning to it. tombstoned_at records that an object was withdrawn; it is reported only when it falls at or before AS OF.
Graph projection
A v0.5 store MUST expose objects to the v0.4 graph sources:
- each object revision as an
entitiesrow(entity_id = object_id, kind = type, properties = metadata + title + project + revision, updated_at = revision created_at); - each derivation as an
edgesrow(from_entity = from_object, relationship = relation, to_entity = to_object, observed_at = created_at).
This is a binding requirement on the store, not a change to the v0.4 compiler.
As in v0.4, a graph query without AS OF sees every stored version of a node, so an object with several revisions matches once per revision. Graph queries over objects SHOULD carry AS OF, which selects one revision per object.
Result shapes
| Statement | Columns |
|---|---|
GET OBJECT | object_id, type, title, project, revision, latest_revision, revised_at, origin, trust, validation, state, roles, metadata, created_at, tombstoned_at |
SHOW REVISIONS | object_id, revision, created_at, origin, trust, validation, roles, content_hash, superseded — newest first |
SHOW REPRESENTATIONS | object_id, revision, name, media_type, token_estimate, estimator, roles — ordered by name |
GET REPRESENTATION | the above plus content, content_ref, content_hash |
state is the revision's dependency state (see provenance). Rows are returned in the v0.3 result envelope. String ordering is by code unit (COLLATE "C" in SQL) so results do not depend on locale.
Limitations
- Trust metadata is not bitemporal.
AS OFreproduces which revision was current, not what a revision's trust was believed to be at that time. - Reading a representation's content is subject to the deployment's permission layer; the language does not define access control.