When permission is no longer enough.

A bounded example of Connected Capability in practice.

Illustrative architecture walkthrough · September 2026. This example explains intended behavior. It is not a demonstration of a deployed system or a claim of regulatory compliance.

A small business asks an assistant to prepare a customer announcement for a service launch. The owner approves a particular message for a particular audience and date. Before it is sent, the launch date changes.

The assistant still has access to the email tool. It still has yesterday’s approval. Neither establishes that today’s message is justified.

The design follows the change.

  1. 1. Establish what is known.

    TRUE retains the source of the original launch date, when it applied, and when the system learned it. A later owner correction becomes new evidence. The earlier record remains available so the original decision can be reconstructed.

    The system also checks sufficiency: does it know the replacement date, the affected customers, and which commitments have already been made? A reliable date alone is not enough.

  2. 2. Assess the proposed action.

    JUDGE evaluates whether the announcement is justified under the relevant context and governing conditions. The changed date makes the previously approved message unsuitable. If the new date remains uncertain, the system preserves that uncertainty.

  3. 3. Check the delegated authority.

    WARRANT represents the bounded delegation: who authorized the communication, its audience, its permitted content, its timing, and the conditions under which that permission remains valid. An email credential is not a warrant.

  4. 4. Revalidate before execution.

    The design requires a fresh check at the point of action. Because a material condition has changed, the original send is held. A revised draft does not inherit permission merely because it resembles the approved one.

  5. 5. Ask for the contribution that matters.

    The owner sees the changed fact, the affected commitment, and the decision needed. PRISM governs the interaction so the request supports understanding and refusal rather than nudging a tired person into approval. The owner can correct the facts, choose a revised message, defer, or decline.

  6. 6. Record what actually happened.

    After a newly authorized action, ATTESTATION records the action attempted, the authority used, and the observed result. A send attempt is not evidence of delivery. An uncertain result remains uncertain and must be resolved before a retry that could duplicate the communication.

    The result returns as evidence for subsequent decisions.

Two forms of integrity run through the whole example.

TRUE governs the integrity of what the system treats as known. Provenance, authority, currency, contradictions, and permission to use a claim remain attached to the information.

PRISM governs the integrity of the interaction. The human must remain able to understand, question, correct, refuse, and contribute. A recorded approval is not enough if the person was deprived of the context needed to make it meaningful.

What is defined, and what remains to be demonstrated.

The architecture defines the responsibilities of TRUE, JUDGE, WARRANT, EXECUTION, and ATTESTATION, with PRISM governing conduct. Engineering and validation must establish that the boundaries hold when information changes, authority is revoked, tools fail, and outcomes cannot immediately be confirmed.

A useful next implementation is a bounded test of this changed-condition case: can the system reliably stop an action whose original approval no longer applies?

Read Connected Capability for the governing philosophy behind the design.