Markets/en/Portal:All Portals/Contract-Structures: Difference between revisions

= Contract Structures — State & Transition Framework =

From WikiDeal, the Wikipedia of e-commerce · Pilot 1, Prototype 1 · ''Socio-Technical Innovation by Théo Bondolfi''

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.

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.

* '''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.

=== Stage 1 — Contact / Sourcing ===

=== Stage 2 — Formalization & Configuration (Negotiation or Selection) ===

By simply selecting from a conditional menu (e.g., volunteer vs. paid), the downstream consequences—such as termination conditions, required benefits, and compensation milestones—automatically adapt without any manual legal drafting.

=== Stage 3 — Fulfillment & Active Execution ===

=== Stage 4 — Resolution / Delivery / Amendment ===

=== Stage 5 — Post-Deal (Evaluation, Rewards & Arbitration) ===

'''Effect'''Mutual evaluation forms sent and collected. Miles/reputation credits distributed according to performance rules. Contract archived in both parties' WikiDeal history. Aggregate anonymised data contributed to User Group analytics.

=== Beyond the Single Deal — Structural Continuity ===

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.

| 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.

== 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.

* '''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.

* [[Gov/en/Portal:R&D/Open-Call:Main|Open Call]]