Operational Model / Draft v0.1
Beacon Cycle:
responsibility before action.
Beacon Cycle translates stable guiding principles into responsibility design, pre-execution assurance, authorized action, verifiable records, independent verification, and evidence-based redesign.
実行前に条件を確認し、実行後に証拠と責任を検証できる形で残すための運用モデルです。
Cycle
Six steps around
a stable Beacon.
Open full-size diagram
Step 01
Responsibility Design
Translate the Beacon into conditions, evidence requirements, responsibility boundaries, approval rules, and exception handling.
Step 02
Pre-Execution Assurance
Before the specified state change, evaluate required evidence, authority, approvals, policy version, pre-operation state, and expected scope of effect.
Step 03
Transition-Authorized Action
Execute only the specified operation when its transition authorization is AUTHORIZED. A review-required or unauthorized result does not establish execution authority.
Step 04
Verifiable Record
Bind decision, conditions, evidence, approvals, unverified conditions, pre-state, and result.
Step 05
Independent Verification
Confirm from outside the executor whether design, assurance, execution, and records stayed consistent.
Step 06
Review & Redesign
Use verification results to revise conditions, boundaries, evidence requirements, approvals, and verification methods.
Transition Authorization
Verification alone
does not authorize action.
Evidence and policy conditions are evaluated at the relevant execution time. The result is then mapped to an explicit transition authorization for the specified state change.
AUTHORIZED: all required evidence, authority, approvals, and policy conditions are satisfied for the specified transition.
REQUIRES_REVIEW: evidence is missing, ambiguous, stale, or outside the acceptable window; no automatic execution authority is established.
NOT_AUTHORIZED: required conditions are not satisfied; the specified state transition remains unauthorized.
AUTHORIZED is a protocol-level state for a specified operation. It does not
create legal, regulatory, contractual, safety, or organizational authority that did not otherwise exist.
PDCA Relationship
Not a replacement
for PDCA.
PDCA asks how an organization improves its work. Beacon Cycle asks whether an important action was permitted under defined conditions and whether that decision remains independently verifiable.
Aspect
PDCA
Beacon Cycle
Main concern
Performance and process improvement.
Justifiable, verifiable decisions and actions.
Sequence
Plan, Do, Check, Act.
Design, assure, authorize, record, verify, redesign.
Before
execution
Usually does not define a machine-checkable authorization condition.
Requires an explicit transition-authorization result before the specified state change.
PDCA implementations may include preventive controls and approval procedures. This comparison concerns the core purpose of the cycle: continuous process improvement versus explicit, machine-checkable transition authorization and replayable assurance records.
Foundations
One model,
three supporting layers.
ROS
Responsibility OS
Conceptual and formal foundation for binding decisions, responsibility, evidence, unverified conditions, and state transitions.
HAAP
Hiroshima AI Assurance Protocol
Interoperability layer for requirements, evidence, verification outcomes, adoption states, and authorized transitions.
ADIC
Advanced Data Integrity by Ledger of Computation
Provides reference implementation patterns for replayable records, independent recalculation, integrity verification, and post-execution comparison.
Apply
Use it where
conditions matter before action.
Illustrative domains include pharmaceutical logistics, critical configuration changes, and AI agent delegation. Beacon Cycle is not a certification scheme, legal guarantee, or automated ethics score.