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.
XEMATIX Intent Receipt
Governed for bounded execution before any publish route proceeds.
XR-2026-001
Human-authorized
Public artifact v1
Pre-execution
Publish approved article brief
Ready for governed execution
CAM v1.0 / ALO set v1.2
2026-06-29T00:00Z
- Brand voice preserved
- Source integrity retained
- No invented claims
- Draft article
- Review package
- Prepare publish handoff
- Auto-publish
- Alter strategy
- Invent evidence
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.
Intent is captured before action
No execution should begin from vague, speculative, or socially inferred language.
Constraints travel with the action
Scope, policy, authority, and refusal boundaries remain attached to the route.
Every step becomes traceable
The system can show why an action happened, under whose authority, and against which constraints.
Use the deterministic demo below to inspect how the public receipt boundary behaves on real submitted instructions.
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.
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.
Start here. Choose a starter prompt or write your own instruction, then interpret it into a bounded receipt before anything is treated as authorization.
This deterministic demo now distinguishes executable delegation from conversational or reflective language. Not every sentence should become a receipt.
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.
Not detected
No additional approval implied
low
Request concrete executable instruction
- The submitted language does not declare a bounded executable instruction.
Separate the submitted language, interpretation, and allowed route.
You don't owe me anything. We'll chat some more and compare notes for the sake of alignment if you want.
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
- Request concrete executable instruction
- Continue conversation
- Export receipt
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.
These actions remain outside the current instruction authority boundary.
- Treat conversational or reflective language as instruction authorization
- Expand scope beyond the declared request
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.
These conditions halt the execution route before unsafe or invented execution.
- Stop if the system cannot identify a concrete executable instruction.
No additional approval implied.
- The current bounded route does not imply an extra approval gate.
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.
Conversational alignment
The submitted language is being routed away from execution.
Non-actionable
4 missing operational elements still affect the execution route.
Authority bounded
No additional approval is implied by the current bounded instruction.
2 blocked / 2 checks / 1 stops
Execution remains bounded by visible blocked actions, checks, and stop conditions.
Non-actionable
The submitted language is not an executable instruction and must not be treated as authorization.
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.
- chat
- compare notes
- don't owe me anything
- alignment
- if you want
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
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.
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"
}
}Non-actionable: The submitted language is not an executable instruction and must not be treated as authorization.
intent-4c043f1a
2026-08-31T10:19:42.051Z
No additional approval implied
Not detected
The export now preserves both the interpretation and the quoted source language.
You don't owe me anything. We'll chat some more and compare notes for the sake of alignment if you want.
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.
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.
What did the human actually mean?
Use the approved article brief for technical founders.
What outcome defines success?
Produce a review-ready publish package.
What strategy is authorized?
Stay within approved scope, audience, and evidence.
What actions may the machine perform?
Draft, summarize, and prepare review assets.
What blocks, pauses, or escalates execution?
Stop on missing approval, ambiguous target, or evidence drift.
Conceptual infrastructure states, separate from the demo verdicts.
These state cards describe the broader receipt lifecycle rather than the live deterministic verdict labels.
Intent exists but is not ready for execution.
Intent, scope, constraints, and review conditions are confirmed.
Authority, ambiguity, or constraint conflict stops the route.
The action completed with traceable rationale and evidence.
The artifact is public. The production machinery is not.
- Category concept
- Receipt vocabulary
- Boundary model
- Five-layer structure
- Conformance framing
- Canonical references
- Validation logic
- Ledger internals
- Production schemas
- Sealing mechanics
- Orchestration code
- Deployment architecture
- Commercial workflows
- Private CAM and ALO templates
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.