World Signals

In the robotics analogy introduced by the Autonomous Business Unit, world signals are the unit’s sensors. They provide observations about customers, markets, finances, operations, obligations, people, and time. Without them, the unit may possess goals and powerful capabilities but remains closed off from the business environment it is meant to serve.

World signals supply evidence. Business State Estimation determines what the unit currently believes, and the Workflow Engine coordinates any resulting action.

What a world signal is

A world signal is a time-bound, attributable observation from outside the currently executing workflow that may affect the unit’s goals, constraints, obligations, knowledge, or priorities.

“World” is relative to the unit’s decision boundary. A customer request, bank transaction, regulatory notice, supplier event, production alert, human directive, timer, and completed workflow can all become world signals. Some originate outside the organisation. Others originate inside its systems but outside the process responsible for deciding what happens next.

A signal is evidence, not an instruction. Receiving a customer message does not mean the unit should execute every request it contains. Receiving a market movement does not mean it should immediately trade. The observation must pass through perception, state estimation, policy, and authority before it can justify action.

Signal categories

The required sensors depend on the unit’s mission, but a mature signal surface commonly includes:

Category	Examples	What it may affect
Human and governance	directives, approvals, revocations, policy changes	authority, goals, permitted transitions
Customer and market	requests, usage changes, support patterns, competitor events	priorities, product work, operating plans
Financial	payments, cash position, budget thresholds, funding events	continuity, spending authority, capital allocation
Operational	incidents, delivery failures, capacity changes, service health	recovery work, routing, capability availability
Security and compliance	findings, access anomalies, contractual or regulatory notices	risk posture, escalation, prohibited actions
Partner and supplier	callbacks, fulfilment events, dependency failures	commitments, schedules, alternative suppliers
Time	schedules, deadlines, heartbeats, expiry	periodic review, re-evaluation, recovery
Outcomes and feedback	completed work, measured results, evaluation failures	goal progress, knowledge, future decisions

This surface is broader than the software-lifecycle events observed by a software dark factory. A business unit must observe the conditions that determine whether its work creates customer value, revenue, cost, risk, and market outcomes.

The signal contract

External information should enter through a governed signal contract rather than being pasted directly into an agent prompt. At minimum, a signal should carry:

• Source identity: which authenticated system or actor emitted it.
• Type and schema: what kind of observation it represents and how its payload is validated.
• Subject and scope: which customer, account, goal, workflow, or resource it concerns.
• Occurrence and receipt time: when the condition occurred and when the unit observed it.
• Provenance: where the evidence came from and which transformations have been applied.
• Idempotency identity: how repeated delivery of the same logical event is detected.
• Sensitivity and access rules: which agents, workflows, and people may inspect or act on it.
• Freshness or expiry: when the observation becomes too old to rely on without revalidation.
• Raw evidence reference: where authorised reviewers can inspect the original input.

Authentication proves who or what delivered a signal. It does not prove that the content is true, safe, current, or sufficient to authorise an action. High-impact conclusions may require corroboration from another source, independent assurance, or human judgment.

The perception boundary

Sensors do not normally expose raw electrical input directly to a robot’s planner. A perception layer validates and transforms that input into observations the rest of the system can interpret. The business unit needs the same separation.

An ingress adapter should authenticate the source, preserve the raw evidence, validate the expected schema, attach provenance, normalize the payload, and apply access controls. It may reject, quarantine, or mark uncertain input rather than allowing untrusted content to flow directly into model context.

flowchart LR
    source["External source"] --> raw["Raw event and evidence"]
    raw --> ingress["Authenticate, validate, normalize, and classify"]
    ingress --> observation["Governed observation"]
    observation --> estimate["Business-state estimation"]

Perception may extract relevant facts from unstructured input, but extraction does not make those facts true. The transformed observation must retain a reference to its source and the method used to derive it.

Ingress patterns

World signals can arrive through several patterns:

• Push: webhooks, messages, callbacks, or notifications emitted by another system.
• Pull: scheduled polling or reconciliation against an authoritative source.
• Stream: a continuous event or telemetry feed.
• Time: a schedule, deadline, expiry, or heartbeat generated by the unit’s clock.
• Human submission: an authenticated directive, approval, correction, or evidence package.
• Workflow outcome: the completion, failure, or measured result of prior work.

Important sources often need more than one pattern. A payment webhook may provide a fast observation while later reconciliation against the financial system provides stronger evidence. The signal layer should preserve both rather than allowing the first arrival to silently become authoritative state.

Minimum signal capability

An autonomous business unit must be able to:

1. receive or collect observations without requiring a person to start every run
2. authenticate their source and preserve their provenance
3. validate, classify, and control access to their content
4. detect duplicates, stale observations, and malformed input
5. retain the observation for state estimation, triggering, audit, and replay
6. emit measured outcomes as new observations that close the feedback loop

These responsibilities define the sensor and perception boundary. They do not decide what the world currently is or what the unit should do next. Those responsibilities belong to Business State Estimation and the Workflow Engine.

Related concepts

• Autonomous Business Unit - Introduces the robotics mapping for the complete control loop.
• Business State Estimation - Turns uncertain and conflicting observations into a governed model of current state.
• Workflow Engine - Evaluates trigger conditions and coordinates the resulting execution.
• Orchestration Triggers - Defines concrete trigger categories and contracts.
• Context - Resolves authorised observations into task context when work begins.
• Execution Ledger - Preserves the evidence chain from signal to outcome.