Mechanic: Added more mechanics so we have mostly problem/usecase/mechanic-fit

Author: Alwin Mark

doc/02_language/glossary.md

@@ -169,6 +169,110 @@ A decision becomes relevant to Noesis only if it affects:
 - or mechanics
 
 
+---
+
+
+## Learning Signal
+
+A Learning Signal is an explicit, observable outcome
+that reduces uncertainty and informs a decision.
+
+In Protopipe, a learning signal:
+- is tied to a hypothesis or experiment
+- is measurable or at least falsifiable
+- influences a decision or next step
+
+Activity, delivery, or effort alone
+do not constitute a learning signal.
+
+---
+
+## Business Ownership
+
+Business Ownership describes responsibility
+for hypotheses, experiments, and learning outcomes.
+
+In Protopipe, business ownership means:
+- defining the learning intent
+- owning the interpretation of results
+- being accountable for decisions based on learning
+
+Business ownership is independent of technical implementation
+and is typically held by:
+- stakeholders
+- product owners
+- product managers
+
+Ownership cannot be delegated without responsibility.
+
+---
+
+## Explicit Shared Meaning
+
+Explicit Shared Meaning refers to information
+that is intentionally expressed, referenceable,
+and understood consistently across roles.
+
+In Protopipe, shared meaning is:
+- written down
+- canonical or explicitly versioned
+- used as a reference instead of verbal alignment
+
+Meaning that exists only in conversations,
+presentations, or individual interpretation
+is considered implicit and non-canonical.
+
+---
+
+## Coordination
+
+Coordination is the act of aligning work,
+decisions, or responsibilities across people or teams.
+
+In Protopipe, coordination is considered a cost,
+not a goal.
+
+Coordination is only valid
+when it is based on explicit shared meaning.
+Implicit alignment increases coordination overhead
+and is treated as structural risk.
+
+---
+
+## Attribution Context
+
+Attribution Context is the minimal set of information
+required to relate signals to intent and outcome.
+
+In Protopipe, attribution context includes:
+- experiment context
+- process context
+- user context
+
+Attribution context must be attached
+at the point where events or telemetry are emitted
+and propagated unchanged downstream.
+
+Signals without attribution context
+cannot be evaluated meaningfully.
+
+
+---
+
+## Experiment Evaluation
+
+Experiment Evaluation is the act of interpreting
+experiment results to inform a decision.
+
+In Protopipe, experiment evaluation:
+- depends on complete attribution context
+- focuses on learning, not success or failure
+- results in a decision, continuation, or discard
+
+Evaluation is distinct from reporting or visualization.
+An experiment without evaluation is incomplete.
+
+
 ---
 
 ## Protopipe Portfolio (ProtoPortfolio)
@@ -464,6 +568,38 @@ Benefits:
 - clear Definition of Done at merge time
 - reproducible experiment results
 
+---
+
+## Reverse Feedback Loop
+
+The Reverse Feedback Loop describes the inversion
+of the classic **Build–Measure–Learn** cycle
+during planning and decision-making.
+
+While execution follows:
+
+Build → Measure → Learn
+
+planning follows the reverse direction:
+
+Learn → Measure → Build
+
+---
+
+In the Reverse Feedback Loop, work does not start from features
+or solutions, but from learning intent.
+
+Decisions are planned by defining:
+- what needs to be learned
+- how learning will be measured
+- what must be built to generate that learning
+
+The concept originates from **Lean Startup**
+and is used in Protopipe
+to enforce learning-first planning
+and prevent solution-driven execution.
+
+
 ---
 
 ## Atomic Design (Reference Model)

doc/06_mechanics/approved/M-009_no-experiment_without_explicit-testgroup-assignment.md

@@ -0,0 +1,64 @@
+# Mechanic: No Experiment without Explicit Testgroup Assignment
+
+## Intent
+
+Prevent implicit exposure and unverifiable experiments
+by enforcing explicit user group assignment.
+
+---
+
+## Problems Addressed
+
+- Decisions Without Feedback
+- Learning Is Optional
+- Feature Pressure Over Innovation
+
+---
+
+## Use-Cases Enabled
+
+- CPO validates outcomes during delivery
+- Teams run interpretable experiments
+- Management reasons about causality
+
+---
+
+## Enforced Behavior
+
+This mechanic enforces that:
+
+- every experiment defines explicit test groups
+- group assignment is intentional and visible
+- assignment may be randomized or equalized
+- experiments without assignment are invalid
+
+If no explicit assignment exists,
+the experiment must not run.
+
+---
+
+## Structural Constraints
+
+- “silent rollout” experiments are forbidden
+- attribution without grouping is impossible
+- learning requires deliberate exposure design
+
+---
+
+## Mechanic Boundary
+
+This mechanic:
+- enforces explicit exposure semantics
+
+This mechanic does **not**:
+- prescribe assignment techniques
+- define persistence or tracking mechanisms
+
+---
+
+## Failure Modes
+
+- experiments rely on implicit traffic splitting
+- assignment exists but is not enforced
+- groups are defined but not respected
+

doc/06_mechanics/approved/M-010_no-backend-client-state_without_domain-owned-state.md

@@ -0,0 +1,62 @@
+# Mechanic: No Backend-Controlled Client State without Domain-Owned State
+
+## Intent
+
+Prevent hidden coupling and opaque behavior
+by enforcing explicit ownership of client-related state.
+
+---
+
+## Problems Addressed
+
+- High Coupling, Low Fault Locality
+- Untestable Architecture
+- Implicit Knowledge and Fragmented Contexts
+
+---
+
+## Use-Cases Enabled
+
+- Teams reason about client behavior deterministically
+- Failures are attributable and reproducible
+- State becomes inspectable and auditable
+
+---
+
+## Enforced Behavior
+
+This mechanic enforces that:
+
+- backend systems must not control client state implicitly
+- client-relevant state must belong to an explicit domain object
+- state transitions are observable and owned
+
+Backend-controlled implicit state is forbidden.
+
+---
+
+## Structural Constraints
+
+- convenience-based state hacks are prevented
+- hidden behavioral coupling is removed
+- debugging shifts from inference to inspection
+
+---
+
+## Mechanic Boundary
+
+This mechanic:
+- governs ownership of client-relevant state
+
+This mechanic does **not**:
+- define storage technology
+- mandate frontend architecture
+
+---
+
+## Failure Modes
+
+- state is hidden in transport or infrastructure layers
+- ownership is unclear
+- behavior depends on invisible state
+

doc/06_mechanics/approved/M-011_polling_over_push-sockets.md

@@ -0,0 +1,60 @@
+# Mechanic: Polling over Push Sockets
+
+## Intent
+
+Avoid hidden coupling and scaling complexity
+by enforcing pull-based state synchronization.
+
+---
+
+## Problems Addressed
+
+- High Coupling, Low Fault Locality
+- Untestable Architecture
+- Integration Layer Lock-In
+
+---
+
+## Use-Cases Enabled
+
+- Systems scale predictably
+- Failure modes are observable
+- Clients remain loosely coupled
+
+---
+
+## Enforced Behavior
+
+This mechanic enforces that:
+
+- clients retrieve state via polling
+- push-based socket communication is not the default
+- synchronization remains explicit and observable
+
+Push-based coupling requires explicit justification.
+
+---
+
+## Structural Constraints
+
+- real-time convenience is traded for robustness
+- implicit server-to-client coupling is avoided
+
+---
+
+## Mechanic Boundary
+
+This mechanic:
+- governs default synchronization semantics
+
+This mechanic does **not**:
+- forbid push communication categorically
+- define polling intervals or protocols
+
+---
+
+## Failure Modes
+
+- push channels reintroduced implicitly
+- polling treated as implementation detail
+

doc/06_mechanics/approved/M-012_explicit-exit-events_over_implicit-process-transactions.md

@@ -0,0 +1,60 @@
+# Mechanic: Explicit Exit Events over Implicit Process Transitions
+
+## Intent
+
+Increase testability and observability
+by making process boundaries explicit.
+
+---
+
+## Problems Addressed
+
+- Untestable Architecture
+- Analysis as a Side Effect
+- High Coupling, Low Fault Locality
+
+---
+
+## Use-Cases Enabled
+
+- Synthetic process testing
+- Deterministic failure analysis
+- Explicit quality gates
+
+---
+
+## Enforced Behavior
+
+This mechanic enforces that:
+
+- every process transition has explicit exit events
+- success and failure paths are modeled
+- implicit transitions are forbidden
+
+A transition without an exit event is invalid.
+
+---
+
+## Structural Constraints
+
+- process modeling effort increases
+- implicit control flow is eliminated
+
+---
+
+## Mechanic Boundary
+
+This mechanic:
+- governs process boundary semantics
+
+This mechanic does **not**:
+- prescribe process granularity
+- define event payload structure
+
+---
+
+## Failure Modes
+
+- exit events exist but are ignored
+- failure paths are modeled but not handled
+