Contract Structures — State & Transition Framework
WikiDeal provides User Groups with a key lever for deploying the success conditions of each contract. This framework maps contract execution through states and transitions — making it easy for social entrepreneurship federations to incubate and operate with clarity. Every contract is a living object: it has a position in a lifecycle, conditions that govern its movement, and effects that follow automatically from each transition.
1 The State & Transition Model
Every WikiDeal contract is not merely a static document — it is a stateful object that evolves through well-defined stages. At any point in time, a contract occupies a specific state, and it moves to the next state only when the conditions for that transition are met.
Before signing, every contract begins in the Negotiation state. This is not passive waiting — it is an active phase where parties verify conditions, exchange terms, and confirm readiness. The transition out of Negotiation is triggered only when pre-conditions are satisfied on all sides.
The framework is designed so that User Groups — social entrepreneurship federations, cooperatives, community markets — can configure the exact conditions and effects appropriate to their context, while relying on a shared structural backbone.
1.1 Key Concepts
The State & Transition Model distinguishes five fundamental building blocks:
- Pre-conditions (upstream conditionals / prérequis): Criteria that must be verified as true before a state change is permitted. Examples: identity verified, deposit received, inventory confirmed. If a pre-condition is not met, the transition is blocked until it is resolved.
- Consecutive effects (downstream / résultats): Actions or changes that follow automatically and immediately from a state transition. Examples: payment released, certificate issued, notification sent to all parties. These are deterministic — no further conditions required.
- Conditional results: Outcomes that occur as a consequence of a transition only if specific additional conditions are true at that moment. Example: a loyalty bonus is triggered only if the buyer has completed at least 3 prior purchases.
- Invariant results: Outcomes that always follow a state transition, regardless of any other conditions. Example: a timestamped record is always created upon contract signature. Invariant results are the non-negotiable backbone of trust and traceability.
- Adaptive modalities: Flexible parameters built into the contract that allow parties or the platform to adjust the terms in defined ways. Each modality specifies: the type of adaptation permitted (e.g., deadline extension, price revision), the variables that can change (amount, date, scope), and the conditions that must exist before the adaptation is allowed. Adaptive modalities prevent disputes by pre-authorizing controlled flexibility.
2 Contract Lifecycle Stages
Every WikiDeal contract passes through five canonical stages. The transitions between stages are governed by the pre-conditions, effects, and modalities described in Section 1.
Stage 1 — Contact / Sourcing
Stage 2 — Formalization & Configuration (Negotiation or Selection)
WikiDeal replaces traditional, heavy negotiation with smart configuration. Instead of drafting terms from scratch or arguing over clauses, parties use flexible, pre-defined conditional dropdowns to shape the agreement. The "Success Conditions Toolkit" instantly adapts the subsequent rules based on these configuration choices.
A babysitting arrangement isn't just a standard hiring contract. Through smart configuration, the toolkit offers multiple pre-modeled scenarios in a single flow:
- Mutual shared babysitting between neighborhood families (condition: must accept at least 20% of requests to remain in the network, otherwise deactivated).
- Semi-voluntary babysitting (minor compensation or token exchange).
- Recognizing family caregivers (proches aidants).
- Live-in babysitting during holidays.
- Fully paid babysitting (condition: strict legal work rights required).
Stage 3 — Fulfillment & Active Execution
Stage 4 — Resolution / Delivery / Amendment
Amendments are not merely for fixing issues or resolving disputes. In the WikiDeal framework, they act as the primary mechanism for Renewal (Reconduction) and continuous Adaptation (Adjustment/Iteration). This allows terms to be adapted dynamically so that the contract evolves with changing conditions, rather than having to be torn up and renegotiated from scratch.
Stage 5 — Post-Deal (Evaluation, Rewards & Arbitration)
Beyond the Single Deal — Structural Continuity
WikiDeal contracts are not isolated transactions. They are structurally designed to connect to the future and to the wider community ecosystem through two key mechanisms:
- Follow-on Contracts (Nouveaux contrats qui en découlent): The system facilitates the creation of derivative or new contracts based on the completion and success of the current one. A resolved deal can automatically trigger templates or propose terms for the next logical step in a relationship.
- Broader Program Integration (Inscription dans un programme plus général): Individual contracts do not exist in a vacuum; they nest into and contribute to a broader roadmap, programmatic goal, or Master Agreement of the User Group/Federation. Every contract plays a measurable part in a larger socio-economic fabric.
3 Success Conditions Toolkit
WikiDeal bundles a set of standard tools — levers — into every contract template. User Groups configure which levers are active and how they behave. Here are some initial outputs (six initial components) proposed within the framework of Prototype 1. These tools will be empowered through Open Calls and through a Steering Committee's added value, progressively replaced by the application of selected Open Call results as the platform is funded and evolves.
| Lever | Description | Trigger Condition | Procedure |
|---|---|---|---|
| Adaptive Modalities | Pre-authorised flexibility windows. Each modality defines a type of adaptation (deadline, price, scope), the variables that can change, and the conditions that permit the change. | A defined event occurs within an active execution window (e.g., delay notified within X days, force majeure declared). | The requesting party submits an adaptation request. If within modality parameters, the change is applied automatically and logged. If outside, it escalates to mediation. |
| Compensatory Measures | Predefined penalties or remedies for common failures: late delivery, non-payment, partial fulfilment, quality shortfall. | A milestone is missed or a payment is overdue beyond the defined grace period. | Alert issued to defaulting party. If unresolved within the response window, compensatory measure activates automatically (e.g., escrow partial release, penalty applied). Logged. |
| Mediation & Arbitration Dynamics | Structured escalation from peer mediation to formal arbitration. Mediator pool is maintained by the User Group or WikiDeal network. | A dispute is formally raised by either party, or an adaptive modality request is rejected. | Step 1 — Peer mediation (48h window). Step 2 — User Group mediator assigned (structured session). Step 3 — Binding arbitration if unresolved. All steps logged with outcome records. |
| Fraud Management Procedures | Detection and response protocols for contract fraud: false identity, counterfeit goods, double-spending, malicious termination. | Anomaly detected by platform algorithm, or reported by a party or community observer. | Automatic hold placed on relevant funds/actions. Investigation opened. If fraud confirmed: contract voided, sanctions applied per User Group rules, incident logged in reputation system. |
| Whistleblower / Alert Management | Confidential reporting channel for systemic problems: repeated bad actors, unsafe conditions, platform abuse. Separate from individual dispute handling. | Any party or observer identifies a pattern or risk that goes beyond the scope of a single contract dispute. | Alert submitted via protected channel. Reviewed by User Group governance body (anonymised). Escalated to WikiDeal network oversight if systemic. Feedback provided to reporter within defined window. |
| Diagnostic Procedures → Implementation | Structured process for identifying why a contract failed or underperformed, and feeding lessons into template improvements. | Contract closed with dispute, amendment, or poor evaluation score; or flagged for systemic review by User Group. | Diagnostic questionnaire completed by parties and mediator (if applicable). Root cause identified. If template-level issue: User Group proposes template update. If platform issue: escalated to WikiDeal tech team. Improvement logged in public changelog. |
4 Illustrated Example — Artisan Fair Purchase
To make the framework concrete, consider a minimal but complete use case: a buyer purchases a handmade ceramic object from an artisan at a local fair. WikiDeal is used not because the transaction is complex — it isn't — but because the buyer and the artisan want two specific benefits:
- Traceability of the purchase: Proof of authenticity, date, price, and artisan identity — useful for the buyer, and for the artisan's portfolio.
- Access to artisan-specific benefits: The artisan has configured a small "post-sale" benefit package: a studio visit within 6 months, and a free repair of the purchased object within 2 years.
This is a "Framework Lite" instance: most of the toolkit levers are present in the contract template, but few are expected to activate. There is no escrow, no complex milestone schedule, no anticipated dispute. What is active: the trust layer, the traceability record, and the post-sale benefits mechanism.
4.1 State Transitions
(WikiDeal module)
- Browse → Select: The buyer scans the artisan's WikiDeal QR code or taps the NFC tag on the object. Pre-conditions: artisan is a registered WikiDeal seller, object has been registered as an item. Invariant effect: exploration record created with item ID and timestamp.
- Select → Purchase: Buyer confirms purchase via the WikiDeal module (app or web). Payment processed. Pre-conditions: payment method valid, item still available. Invariant effects: purchase record created, certificate of authenticity generated, artisan notified, item marked as sold.
- Purchase → Benefits Activated: Post-sale benefit package automatically unlocked in the buyer's WikiDeal account. Pre-conditions: purchase confirmed and logged. Invariant effects: studio visit voucher generated (valid 6 months), repair entitlement registered (valid 2 years). Buyer receives welcome message from artisan with next steps.
- Benefits Activated → Evaluation: After the studio visit or at the end of the benefit window, both parties are prompted to evaluate the experience. Pre-conditions: at least one benefit used, or benefit window closed. Invariant effects: evaluation stored in both profiles, Miles credits distributed per participation rules, contract archived.
Even in this simple scenario, the full framework backbone is quietly at work. The fraud detection layer is active — if the artisan were to register the same item twice, it would be caught. The whistleblower channel is available. The diagnostic procedure is ready if the buyer reports a problem with the repair entitlement. None of these will likely fire — but they are there, and their presence is what makes the WikiDeal trust layer meaningful even for a €30 ceramic bowl.