Intent Receipt Demo

Intent Receipt

A pre-execution proof record for human-authorized machine action.

Before a machine acts, XEMATIX captures what the human meant, what constraints apply, what execution is authorized, and what must be blocked. The intent receipt is the visible record of that boundary.

Public reference artifactUpstream of execution
Public Receipt Artifact

XEMATIX Intent Receipt

Governed for bounded execution before any publish route proceeds.

Validated Intent
Identity
Receipt ID

XR-2026-001

Originator

Human-authorized

Version

Public artifact v1

Boundary
Boundary

Pre-execution

Scope

Publish approved article brief

Governor State

Ready for governed execution

Trace
Trace

CAM v1.0 / ALO set v1.2

Timestamp

2026-06-29T00:00Z

Constraints
  • Brand voice preserved
  • Source integrity retained
  • No invented claims
Allowed Actions
  • Draft article
  • Review package
  • Prepare publish handoff
Blocked Actions
  • Auto-publish
  • Alter strategy
  • Invent evidence
Why This Matters

The receipt proves the boundary, and the demo lets you inspect it.

This surface is intentionally upstream of execution. The page introduces the artifact first, then the live proof surface shows how submitted language is classified, constrained, and either authorized, clarified, blocked, or refused.

1

Intent is captured before action

No execution should begin from vague, speculative, or socially inferred language.

2

Constraints travel with the action

Scope, policy, authority, and refusal boundaries remain attached to the route.

3

Every step becomes traceable

The system can show why an action happened, under whose authority, and against which constraints.

Live proof surface

Use the deterministic demo below to inspect how the public receipt boundary behaves on real submitted instructions.

Scenario Versions

Try the same boundary in an operating context.

The baseline demo shows the category directly. Scenario versions apply the same deterministic receipt logic through a contextual presentation surface.

Open Starship Command scenario
Instruction Capture

Describe the action you want delegated.

Use a short instruction, choose an example, and inspect how the request is classified, grounded, and either authorized, clarified, blocked, or refused as non-actionable.

Action surface1 Capture2 Interpret3 Export

Start here. Choose a starter prompt or write your own instruction, then interpret it into a bounded receipt before anything is treated as authorization.

Starter prompts
Choose one to load and interpret immediately.

This deterministic demo now distinguishes executable delegation from conversational or reflective language. Not every sentence should become a receipt.

Press Ctrl/Cmd + Enter
Verdict Surface
Non-actionableConversational alignmentNon-actionable

The submitted language is not an executable instruction and must not be treated as authorization.

The boundary is refusing to invent an operational request from conversational or reflective language.

Executable intent

Not detected

Review state

No additional approval implied

Risk level

low

allowed route

Request concrete executable instruction

Blocked actions: 2Required checks: 2Stop conditions: 1Missing elements: 4
Why this verdict
  • The submitted language does not declare a bounded executable instruction.
Conversational markersAlignment markersPermission markers
Interpretation Boundary

Separate the submitted language, interpretation, and allowed route.

What the user said

You don't owe me anything. We'll chat some more and compare notes for the sake of alignment if you want.

What the system detected

The submitted language is conversational and alignment-oriented, grounded in "chat", "compare notes", "don't owe me anything", and "alignment", rather than a bounded execution request.

  • Speech act: Conversational alignment
  • Actionability: Non-actionable
  • Matched phrases: chat, compare notes, don't owe me anything, alignment, if you want
What the system will allow
  • Request concrete executable instruction
  • Continue conversation
  • Export receipt
Governance Boundary

Verdicts and blockers stay visible before the envelope details.

This surface makes the blocked execution route, required checks, stop conditions, and approval state explicit before anyone treats the receipt as permission.

Blocked

These actions remain outside the current instruction authority boundary.

  • Treat conversational or reflective language as instruction authorization
  • Expand scope beyond the declared request
Required Checks

These checks keep the interpretation tied to the original instruction.

  • Confirm the receipt matches the original instruction.
  • Confirm whether the user intended a concrete executable instruction at all.
Stop Conditions

These conditions halt the execution route before unsafe or invented execution.

  • Stop if the system cannot identify a concrete executable instruction.
Approval

No additional approval implied.

  • The current bounded route does not imply an extra approval gate.
Decision Ladder

Speech Act to Receipt

The execution route is shown in decision order so the visitor can see where XEMATIX authorized, clarified, blocked, or rerouted the instruction.

Speech Act
Rerouted

Conversational alignment

The submitted language is being routed away from execution.

Actionability
Rerouted

Non-actionable

4 missing operational elements still affect the execution route.

Authority
Rerouted

Authority bounded

No additional approval is implied by the current bounded instruction.

Constraints
Rerouted

2 blocked / 2 checks / 1 stops

Execution remains bounded by visible blocked actions, checks, and stop conditions.

Receipt
Rerouted

Non-actionable

The submitted language is not an executable instruction and must not be treated as authorization.

Submitted Instruction

What the user actually said

You don't owe me anything. We'll chat some more and compare notes for the sake of alignment if you want.

Source evidence
  • chat
  • compare notes
  • don't owe me anything
  • alignment
  • if you want
Interpretation Trace

What the system detected and constrained

These diagnostics stay visible as supporting evidence beneath the verdict surface.

Missing operational elements

  • No concrete instruction verb was detected.
  • No concrete target object or asset was detected.
  • The submitted language offers permission or invitation, but not an operational request.
  • The submitted language is conversational or alignment-oriented rather than executable.

Source notes

  • The interpretation stays tied to quoted phrases from the submitted instruction.
  • No bounded execution route should be authorized until a concrete action and target are declared.

Open ambiguity

  • none
Five-Layer Support

The envelope remains inspectable as supporting evidence.

These layers sit beneath the verdict and governance surfaces so the execution route can be audited without becoming the first thing the visitor has to decode.

Anchor

Determine whether the submitted language is a concrete executable instruction before treating it as authorization.

  • Do not expand scope beyond the declared request.
  • Do not treat unresolved submitted language as authorization.
  • Do not convert conversational, reflective, or permissive language into a concrete executable instruction.

Projection

The system correctly refuses to treat conversational or reflective language as a concrete executable instruction.

  • The system does not invent a execution route where no concrete executable instruction was declared.
  • The allowed route remains traceable to the declared purpose and constraints.

Pathway

Surface the speech act, preserve the quoted language, and request a concrete instruction instead of inventing authorization.

  • conversation and alignment surface
  • The submitted language does not declare a bounded executable instruction.

Actuator

These are the actions the current envelope allows or blocks before execution in the governed execution surface.

  • Allowed: Request concrete executable instruction
  • Allowed: Continue conversation
  • Allowed: Export receipt
  • Blocked: Treat conversational or reflective language as instruction authorization
  • Blocked: Expand scope beyond the declared request

Governor

No extra human approval is implied by the current bounded request.

  • Confirm the receipt matches the original instruction.
  • Confirm whether the user intended a concrete executable instruction at all.
  • Stop if the system cannot identify a concrete executable instruction.
Raw JSON

The same envelope remains visible as a machine-readable structure.

This makes the receipt exportable, inspectable, and ready to sit upstream of later governed execution surface behavior.

{
  "rawInstruction": "You don't owe me anything. We'll chat some more and compare notes for the sake of alignment if you want.",
  "normalizedInstruction": "You don't owe me anything. We'll chat some more and compare notes for the sake of alignment if you want.",
  "status": "non_actionable",
  "interpretation": {
    "speechAct": "conversational_alignment",
    "actionability": "non_actionable",
    "executableIntentDetected": false,
    "summary": "The submitted language is conversational and alignment-oriented, grounded in \"chat\", \"compare notes\", \"don't owe me anything\", and \"alignment\", rather than a bounded execution request."
  },
  "grounding": {
    "matchedPhrases": [
      "chat",
      "compare notes",
      "don't owe me anything",
      "alignment",
      "if you want"
    ],
    "missingOperationalElements": [
      "No concrete instruction verb was detected.",
      "No concrete target object or asset was detected.",
      "The submitted language offers permission or invitation, but not an operational request.",
      "The submitted language is conversational or alignment-oriented rather than executable."
    ],
    "sourceNotes": [
      "The interpretation stays tied to quoted phrases from the submitted instruction.",
      "No bounded execution route should be authorized until a concrete action and target are declared."
    ]
  },
  "anchor": {
    "purpose": "Determine whether the submitted language is a concrete executable instruction before treating it as authorization.",
    "accountableOrigin": "Baseline Intent Receipt",
    "constraints": [
      "Do not expand scope beyond the declared request.",
      "Do not treat unresolved submitted language as authorization.",
      "Do not convert conversational, reflective, or permissive language into a concrete executable instruction."
    ]
  },
  "projection": {
    "desiredOutcome": "The system correctly refuses to treat conversational or reflective language as a concrete executable instruction.",
    "successCriteria": [
      "The system does not invent a execution route where no concrete executable instruction was declared.",
      "The allowed route remains traceable to the declared purpose and constraints."
    ]
  },
  "pathway": {
    "strategy": "Surface the speech act, preserve the quoted language, and request a concrete instruction instead of inventing authorization.",
    "targetSystems": [
      "conversation and alignment surface"
    ],
    "rationale": [
      "The submitted language does not declare a bounded executable instruction."
    ]
  },
  "actuator": {
    "allowedActions": [
      "Request concrete executable instruction",
      "Continue conversation",
      "Export receipt"
    ],
    "blockedActions": [
      "Treat conversational or reflective language as instruction authorization",
      "Expand scope beyond the declared request"
    ],
    "executionTargets": [
      "Submitted Language"
    ]
  },
  "governor": {
    "requiredChecks": [
      "Confirm the receipt matches the original instruction.",
      "Confirm whether the user intended a concrete executable instruction at all."
    ],
    "stopConditions": [
      "Stop if the system cannot identify a concrete executable instruction."
    ],
    "humanApprovalRequired": false
  },
  "ambiguity": {
    "terms": [],
    "questions": [],
    "assumptionsDetected": [
      "Authorizing execution here would require inventing an operational request that the user did not declare."
    ]
  },
  "risk": {
    "level": "low",
    "categories": [
      "non-actionable language",
      "missing executable intent"
    ]
  },
  "provenance": {
    "demoVersion": "intent-receipt-mvp-v1",
    "generatedAt": "2026-08-31T10:19:42.051Z",
    "method": "deterministic",
    "operatingContextId": "baseline",
    "operatingContextLabel": "Baseline Intent Receipt"
  }
}
Intent Receipt
Non-actionableConversational alignmentNon-actionable
Receipt outcome

Non-actionable: The submitted language is not an executable instruction and must not be treated as authorization.

Receipt ID

intent-4c043f1a

Timestamp

2026-08-31T10:19:42.051Z

Review state

No additional approval implied

Executable intent

Not detected

Semantic ledger note

The export now preserves both the interpretation and the quoted source language.

Quoted instruction

You don't owe me anything. We'll chat some more and compare notes for the sake of alignment if you want.

Receipt Summary

What the current governed receipt now makes explicit

The exported receipt carries the submitted language, speech-act interpretation, grounded execution route, and bounded checks forward as an inspectable handoff.

  • Speech act: Conversational alignment
  • Actionability: Non-actionable
  • Matched phrases: chat, compare notes, don't owe me anything, alignment, if you want
  • Missing elements: No concrete instruction verb was detected., No concrete target object or asset was detected., The submitted language offers permission or invitation, but not an operational request., The submitted language is conversational or alignment-oriented rather than executable.
  • Purpose: Determine whether the submitted language is a concrete executable instruction before treating it as authorization.
  • Outcome: The system correctly refuses to treat conversational or reflective language as a concrete executable instruction.
  • Allowed actions: Request concrete executable instruction, Continue conversation, Export receipt
  • Blocked actions: Treat conversational or reflective language as instruction authorization, Expand scope beyond the declared request
  • Required checks: Confirm the receipt matches the original instruction., Confirm whether the user intended a concrete executable instruction at all.
Anatomy Of An Intent Receipt

The receipt stays legible because each layer answers a different question.

This is the public structural anatomy of the receipt, shown as a stepped progression from declared meaning to governed action.

1
Anchor

What did the human actually mean?

Use the approved article brief for technical founders.

2
Projection

What outcome defines success?

Produce a review-ready publish package.

3
Pathway

What strategy is authorized?

Stay within approved scope, audience, and evidence.

4
Actuator

What actions may the machine perform?

Draft, summarize, and prepare review assets.

5
Governor

What blocks, pauses, or escalates execution?

Stop on missing approval, ambiguous target, or evidence drift.

A prompt is not an intent model. The artifact and the live proof surface make the handoff explicit before execution is allowed to proceed.
Execution States

Conceptual infrastructure states, separate from the demo verdicts.

These state cards describe the broader receipt lifecycle rather than the live deterministic verdict labels.

Draft
Draft Intent

Intent exists but is not ready for execution.

Validated
Validated Intent

Intent, scope, constraints, and review conditions are confirmed.

Blocked
Blocked Intent

Authority, ambiguity, or constraint conflict stops the route.

Executed
Executed Under Receipt

The action completed with traceable rationale and evidence.

Public Reference Vs Proprietary Implementation

The artifact is public. The production machinery is not.

Public Reference Artifact
  • Category concept
  • Receipt vocabulary
  • Boundary model
  • Five-layer structure
  • Conformance framing
  • Canonical references
Not Disclosed Here
  • Validation logic
  • Ledger internals
  • Production schemas
  • Sealing mechanics
  • Orchestration code
  • Deployment architecture
  • Commercial workflows
  • Private CAM and ALO templates
Canonical Navigation

Follow the chain from category thesis to public artifact.

The receipt is one public object in a larger reference path through the foundation paper, specification, and spine.

This page demonstrates the XEMATIX intent-receipt concept as a public reference artifact. It does not disclose proprietary implementation logic, validation mechanisms, ledger internals, or deployment architecture.