mls.x1

Purpose

mls.x1 is the governed listing, discovery, and intake-conversion namespace. It enables structured service and asset listings to be published, discovered, and converted directly into QTM OS intake — without bypassing the execution spine.

Architectural role

mls.x1 sits upstream of intake in the execution chain. It is a pre-execution discovery surface. A listing is a structured artifact that organizes a service or opportunity into a format capable of generating governed intake. The listing itself does not create execution objects.

Position in the execution chain

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

What it governs

• Structured service and asset listing objects
• Listing lifecycle (draft, active, paused, fulfilled, expired, removed)
• Conversion payload generation for intake
• Listing visibility and discoverability controls
• Operator-published service offerings
• Trust signal display (read-only reference to ⭐.x1 — not self-asserted)
• Listing fee model

What it does not govern

• It does not create Job, ServiceEvent, or Record directly.
• It does not replace intake, task review, assignment, or job creation.
• It does not collapse or bypass the execution spine.
• It does not govern marketplace transactions or messaging.
• It does not self-generate trust scores.

Routing rule

Listings from operator-surface contexts MUST convert to the originating operator’s intake unless the funnel is explicitly network-managed. The operator routing invariant is preserved at the listing→intake conversion boundary.

Listing modes

The listing spec defines three modes:

In v0.01, service_offer is the primary mode.

Conversion flow

When a listing is selected for conversion:

1. A conversion payload is generated from the listing’s conversion field.
2. The payload specifies the target surface, operator, and intake kind.
3. An intake is created using that payload.
4. Execution proceeds through the standard governed pipeline.

The listing is referenced in the intake so lineage is preserved. The listing itself does not mutate into execution state.

Key conversion rules

• A listing must convert through intake.
• A listing must preserve its listing_id in the intake it generates.
• A listing must not bypass operator routing or governance.
• A listing must map to a valid surface.

Trust on listings

A listing may include read-only trust context referencing the operator’s ⭐ Signal summary.

{
  "trust": {
    "signal_subject": "qtm-detailing",
    "signal_summary": {
      "eligible": true,
      "active_signal_count": 27
    }
  }
}

This trust context is informational. It does not affect routing or governance and follows the same trust_advisory_effect: "none" principle used elsewhere in QTM OS.

Listing lifecycle

draft → active → paused / fulfilled / expired / removed

• draft — created but not yet visible
• active — published and discoverable
• paused — temporarily not accepting conversions
• fulfilled — work is done
• expired — listing passed its active window
• removed — taken down

What the listing layer is not

• Not a messaging platform.
• Not a transaction system.
• Not an execution runtime.
• Not a reputation system.
• Not a replacement for intake.

Distinction from adjacent namespaces

Invariants

1. Listing MUST NOT create execution objects directly
2. Listing MUST convert through intake
3. Listing MUST preserve lineage — conversion must reference originating listing
4. Listing MUST NOT bypass operator routing rules
5. Trust on a listing MUST be referential (read-only ⭐.x1 reference), not self-declared

Relationships to other layers

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

Current status

Namespace assigned. Schema defined at MLS_LISTING_v0.01. Not yet implemented in runtime or surface layer.

Future direction

Operator-facing listing creation and management. Public or semi-public listing discovery surface. Conversion flow wired to intake. Trust signal display drawing from ⭐.x1 signal history.

Guardrails

• Preserve the distinction between planned, partial, and live.
• Avoid marketing language implying live marketplace behavior.
• Keep conversion-to-intake path explicit and governed.

Related pages

• Execution Spine
• ⭐.x1
• Domain Architecture and Namespace Strategy
• Glossary