Methods
1. Purpose
This document defines the methods used to construct, test, revise, and validate ritual systems within the lab.
Its purpose is to formalize how ritual systems are authored and evaluated procedurally, without introducing taste-based judgment, aesthetic preference, or interpretive reasoning.
Methods govern process, not outcomes.
2. Definition
Methods are repeatable procedural steps applied to the creation and maintenance of ritual system instances.
They define how constraints are derived, how compliance is tested, how violations are identified, and how systems are revised, rejected, or frozen.
Methods do not optimize. They enforce.
3. Constraint Authoring Method
Constraint authoring proceeds in the following order:
- Declare Ritual Provenance
- Declare all remaining design dimensions
- Declare explicit prohibitions per dimension
- Declare structural limits
- Declare lifecycle state
No generation may occur before all declarations are complete.
4. Consistency Checking
Before execution, ritual systems must be checked for:
- internal consistency between dimensions
- absence of implicit permissions
- alignment between provenance and symbolic allowance
- compatibility with platform constraints
Inconsistencies must be resolved structurally, not compensated for in content.
5. Execution Method
Execution refers to the generation of ritual outputs under declared constraints.
During execution:
- outputs are treated as evidence, not success
- deviations are logged, not corrected ad hoc
- no mid-execution constraint changes are permitted
Execution does not validate a system.
6. Evaluation Without Affect
Evaluation is conducted without reference to:
- emotional impact
- aesthetic quality
- preference or enjoyment
- perceived success or failure
Evaluation criteria are limited to:
- constraint compliance
- absence of drift signals
- structural integrity of outputs
Outputs that comply are accepted regardless of appeal.
7. Violation Handling
When a violation is detected:
- the violation is classified by dimension
- the violating output is rejected
- the cause is traced to a structural declaration
Violations trigger revision of structure, not relaxation of rules.
8. Revision vs Rejection
Revision is permitted when:
- violations reveal ambiguous constraints
- declarations conflict unintentionally
- platform limits require structural adjustment
Rejection is required when:
- violations persist across revisions
- expressive behavior cannot be constrained
- drift recurs after re-centering
Rejected systems are archived, not deleted.
9. Iteration Discipline
Iteration explores constraint boundaries.
Iteration must not:
- pursue improvement
- chase output quality
- reduce constraints for convenience
Iteration ends when constraints are proven stable or the system is rejected.
10. Documentation and Logging
All actions must be logged:
- executions
- violations
- revisions
- rejections
Logs must record what changed and why procedurally.
Narrative justification is forbidden.
11. Failure Conditions
These methods are considered failed if:
- evaluation becomes affective
- constraints are altered mid-execution
- violations are tolerated
- revision replaces enforcement
Failure requires suspension of active systems.
12. Systemic Role
Methods ensure that ritual system construction remains procedural, auditable, and resistant to expressive drift.
They translate canonical principles into executable lab practice.