Skip to main content

Governed Output Classes

Purpose

This page is the public registry of output classes for governed transition results.

A desired output is not valid merely because it can be requested, generated, displayed, or technically executed. It remains a candidate until the applicable commitment boundary establishes current standing and binds the result to evidence and receipts.

Core output path

admitted input or request
-> governed evaluation
-> candidate result
-> current authority and policy check
-> Transition Table standing
-> ALLOW / DENY / FAIL-CLOSED
-> receipt_chain / STRP record
-> bounded output disposition
-> optional authorized consequence

Registered output classes

Output classRequired boundaryTypical destinationCurrent posture
Informational responseEvidence and scope sufficient; no consequence-bearing authority inferredUser or requesting interfaceSUPPORTED_BOUNDED_RESPONSE
Action proposalExplicitly remains non-authorizingCommitment-candidate or review pathSUPPORTED_NON_EXECUTING
Commitment requestCurrent policy, delegation, evidence and recoverability must be evaluatedAuthority decision surfaceSUPPORTED_NON_AUTHORIZING_REQUEST
Authority decisionDecision must identify standing, scope, policy and validity windowGoverned transition recordSCHEMA_OR_FIXTURE_SUPPORTED
Disabled execution handoffMust state that no side effect occurredAuthorized executor boundaryDEFAULT_FIXTURE_POSTURE
Denial receiptDenial reason and governing evidence must be preservedOriginating path and continuity recordREGISTERED
Fail-closed receiptMissing or invalid authority, evidence, identity, policy or standing must be namedOriginating path and continuity recordREGISTERED
Quarantine resultUnresolved conflict, provenance, privacy, freshness or custody conditionReview or remediation queueREGISTERED
Committed repository changeDestination handoff and repository mutation authority requiredAuthorized repository and commit historyEXTERNAL_TO_WIKI_AUTHORITY
External communicationRecipient, content, authority and consequence boundary requiredEmail, social, API or messaging surfaceEXPLICIT_AUTHORITY_REQUIRED
Memory or KnowledgeVault mutationCurrent consent, policy, provenance and custody requiredAuthorized memory serviceSERVICE_EXTERNAL
STRP handoffTransition identity, result, hashes, authority and continuity fields requiredNext governed entity or systemCONTRACT_OR_FIXTURE_SUPPORTED
Receipt-chain continuationPrior chain validity plus current standing requiredContinuity or Master-Records pathREGISTERED_CURRENT_VALIDATION_REQUIRED
State-transition summaryMust remain a bounded explanation rather than proof authorityPublic or reviewer-facing surfaceSUPPORTED_PUBLIC_EXPLANATION
Custody recordAuthenticated installation and reconstructability evidence requiredMaster-Records/orchestrationEXTERNAL_NOT_CREATED_BY_WIKI

Required result distinctions

Every result surface should distinguish, where applicable:

candidate_output
admitted_informational_response
action_proposal
commitment_request
authority_decision
execution_handoff
execution_result
custody_result
reconstruction_result

Collapsing these stages into a single “success” state obscures whether anything was authorized, executed, recorded, or independently reconstructable.

Machine-readable support

Relevant machine-readable artifacts may include:

governed session packet
intake result
commitment request
authority decision
disabled execution handoff
denial or fail-closed receipt
manifest and receipt handoff
STRP record
custody receipt
reconstruction report

The artifact must identify its producer and scope. A generated file does not inherit authority merely because it conforms to a schema.

Boundary

Generated output != admitted output.
Admitted response != action authority.
Commitment request != authority decision.
Authority decision != execution evidence.
Execution evidence != custody.
Receipt handoff != Master-Records installation.
Historical reconstruction != current admissibility.

Current status

GOVERNED_OUTPUT_CLASS_REGISTRY_COMPLETE_WITH_EXTERNAL_GATES