namespace · v0.01

⭐.x1

Execution-derived trust signal namespace. ⭐ Signal is a system-emitted, Record-backed trust attribution object emitted after governed execution completes.

private planned conceptual star.x1

⭐.x1

Purpose

⭐.x1 is the execution-derived trust signal namespace. It governs the emission, attribution, lifecycle, and routing eligibility of ⭐ Signal objects — system-emitted trust units derived from completed, governed execution.

Architectural role

⭐.x1 sits downstream of Record in the execution spine. A ⭐ Signal can only exist after a ServiceEvent completes and a Record is sealed. It cannot be created manually. It cannot precede execution.

Position in the execution chain

Job → ServiceEvent → Record → ⭐ Signal (⭐.x1)

With a listing upstream:

Listing (mls.x1) → Intake → Job → ServiceEvent → Record → ⭐ Signal (⭐.x1)

What it governs

  • ⭐ Signal object schema and lifecycle (active, revoked, suppressed)
  • System-emitted trust attribution per completed execution
  • Lineage tracing back to Job, ServiceEvent, and Record
  • Routing eligibility for Omni and discovery layers
  • Revocation and governance controls
  • Operator trust legibility based on execution history

What it does not govern

  • It does not create execution authority.
  • It does not replace runtime source-of-truth records.
  • It does not produce aggregate ratings or scores (see ratings.x1).
  • It does not collapse task, job, service event, record, or settlement layers.
  • It does not represent user-declared or operator-declared trust claims.

Distinction from ratings.x1

ratings.x1 governs aggregate trust scoring, performance history, and eligibility logic — a summary interpretation layer built from historical signals.

⭐.x1 governs the base trust attribution object — the per-execution signal unit. A single ⭐ Signal represents one verified execution outcome. Aggregate trust layers may draw from signal history, but ⭐.x1 does not produce scores itself.

Invariants

  1. ⭐ Signal MUST be system-emitted — not manually created
  2. ⭐ Signal MUST derive from a valid ServiceEvent and Record
  3. ⭐ Signal MUST be attributable — traceable back to Job, ServiceEvent, and Record
  4. ⭐ Signal MUST NOT precede execution
  5. ⭐ Signal MUST NOT replace Record
  6. ⭐ Signal revocation MUST preserve history and lineage

How signals are stored and read

Signals are stored in Planck R2 at:

planck/signals/SIGNAL_STAR_v0.01/{job_id}.json

One file is stored per job, keyed by job_id.

Read-only access paths exist for internal systems:

  • GET /api/signals/by-job/:job_id retrieves the stored signal for a specific job.
  • GET /api/signals/by-operator/:operator_slug retrieves stored signals for an operator.

These endpoints expose signal truth without introducing mutation, scoring, aggregation, ranking, or routing control.

Signal lifecycle

StateMeaning
activeValid and in use
suppressedTemporarily hidden or paused
revokedInvalidated while preserving lineage

Revocation preserves history. A revoked signal leaves a traceable record.

Signal structure

Simplified shape:

signal_id       unique identifier
signal_type     execution trust signal
schema          SIGNAL_STAR_v0.01
status          active | suppressed | revoked
emitted_at      when the signal was created

source
  job_id
  service_event_id
  record_id
  operator_slug
  surface_slug

subject
  subject_type   operator
  subject_id     operator receiving attribution

basis
  emission_reason
  evidence_state
  record_state

score
  value   1
  unit    star

The score field is a per-execution attribution unit. It is not an aggregate score, rating, grade, ranking, or marketplace ordering signal.

Relationships to other layers

This page should be read against the execution spine, Record layer, and Domain Architecture and Namespace Strategy.

Current status

Namespace assigned. Schema defined at SIGNAL_STAR_v0.01. Planck runtime includes post-Record signal emission and minimal read-only signal access for internal systems.

Future direction

Broader routing eligibility, discovery display, suppression/revocation workflows, and aggregate trust derivation remain future layers. ⭐.x1 itself remains the base per-execution signal object and does not produce ranking or scoring logic.

Guardrails

  • Preserve the distinction between planned, partial, and live.
  • ⭐ Signal is not a review widget or user feedback tool.
  • Trust shown on listings or profiles that references ⭐.x1 must be read-only and system-derived.