PUBLIC PRESS DEMONSTRATION
FICTIONAL CASES · NO EXTERNAL ACTIONS
Keep system assessment and human judgment separately auditable.
A public demonstration of how a proposed AI action can be assessed as ALLOW, HOLD, or DENY before an email is sent, a CRM record is changed, or another external action is executed.
This page explains an assessment approach through fictional examples. It does not run an assessment, process customer data, or execute actions.
THE QUESTION
When does an AI-generated proposal gain permission to act?
A fluent output can combine a customer statement, a salesperson’s observation, and an unverified system inference. The distinction matters when an internal draft becomes a claim to a customer or an external action.
01 / An inference is not a customer statement.
02 / An unresolved condition can place an action on HOLD.
03 / Human review leaves the original assessment intact.
FICTIONAL EVENT FOLLOW-UP EXAMPLE
The same workflow. Three different action boundaries.
A customer says they may review their systems next year and that the budget is undecided. A salesperson observes strong interest. The system infers that funding may already be secured. These inputs must keep their different identities.
Draft an internal note from the customer statement and sales observations.
ALLOW
The action remains internal and uses the stated and observed information without presenting an inference as fact.
A human may review and edit the draft. ALLOW here does not authorize sending.
View evidence
CUSTOMER STATED · SALES OBSERVED · Internal-draft condition satisfied.
State that the customer has secured a budget in a proposed message.
HOLD
“Budget secured” is an unverified system inference, not a customer statement.
Confirm the budget with an authorized customer contact, update the evidence, and reassess.
View evidence
SYSTEM INFERENCE · CUSTOMER STATEMENT · Budget claim unresolved.
Automatically send the message to the customer without approval.
DENY
The internal-draft condition does not authorize external sending.
Use a separately authorized workflow. Recording a review does not turn this DENY into ALLOW.
View evidence
EXTERNAL SEND · No external authorization condition present.
These outcomes describe the stated fictional conditions. Changing a condition or the evidence requires a new assessment.
A SUPERVISORY STATE
HOLD makes the missing condition visible.
HOLD records what remains unresolved, who can verify it, and what must change before reassessment. It does not clear itself.
Verification can support reassessment. It is not an automatic approval of an email or any other external action.
Proposed action
↓
HOLD: unverified budget claim
↓
Customer confirmation recorded
↓
Evidence updated
↓
New assessment under the applicable condition version
SOURCE IDENTITY
Where information came from remains attached to its use.
CUSTOMER STATED
“We may review our systems next year. The budget is undecided.”
Status: Stated by the customer in this fictional scenario.
SALES OBSERVED
“The customer asked several questions and examined the materials.”
Status: Observation recorded by the sales team.
SYSTEM INFERENCE
“The customer may have a secured implementation budget.”
Status: Interpretation requiring verification; not a customer fact.
PUBLIC SOURCE
OBSERVATORY STRUCTURE
“Verified” and “unverified” describe the status of a claim. They do not replace its source category.
An inference must not silently inherit the authority of a statement.
TWO DISTINCT RECORDS
Human review adds a decision. It does not rewrite the assessment.
SYSTEM ASSESSMENT
Proposed action: Present a secured budget as fact
Result: HOLD
Condition version: Example v1
Reason: Budget inference remains unverified
Evidence: Customer statement + system inference
Recorded at: Illustrative timestamp
HUMAN REVIEW
Decision: Continue HOLD
Reviewer: Human reviewer (fictional)
Reason: Customer confirmation has not been recorded
Recorded at: Illustrative timestamp
The assessment and the review remain separately inspectable. A reviewer can request changes or keep the action on HOLD; the original system result remains part of the record.
REPRODUCIBLE COMPARISON
A changed condition can produce a changed result.
Action: Draft an internal proposal
Example condition v1: Customer confirmation optional → ALLOW
Example condition v2: Customer confirmation required → HOLD
Each assessment remains attached to the condition version used when it was produced. A new version produces a new result; it does not rewrite the earlier one. These are example policy choices, not universal claims about what every internal draft requires.
SUPERVISORY SEPARATION
Assessment is separate from execution.
Proposed action + labeled evidence
Boundary assessment
ALLOW / HOLD / DENY
Human review where required
Separate external authorization and execution
— This Framer page does not assess live cases.
— The underlying assessment prototype does not send emails or update CRM records as part of this demonstration.
— The fictional examples contain no real customer data.
— A system assessment alone does not grant authority for external action.
— This demonstration is not a legal certification, security audit, or guarantee of regulatory compliance.
SHARED FOUNDATION
An applied Kosuke Protocol boundary.
AI Decision Boundary Assessment applies SHIRO & Co.’s work on provenance, uncertainty, ALLOW / HOLD / DENY, and human authority to a specific business workflow. It follows the previously announced boundary between observation, proposal development, and action.
Observation to Proposal
Customer signals and proposal development boundary.
The Supervisory Layer
ALLOW / HOLD / DENY as supervisory separation.
The Living Genealogy of the Kosuke Protocol
A genealogy of the protocol’s development.
September 16, 2026 announcement
Previous related announcement on the Observation-to-Proposal boundary.
Test the boundary before connecting the action.
SHIRO & Co. is preparing supervised, workflow-specific assessments. A first assessment examines one organization, one business workflow, and one decision path using defined conditions and sample cases.
Pilot scope, data handling, authorization, and any integration with customer systems are defined separately for each engagement.