What does it do?
Feature Description
A user can use the Agreement Site (hereafter 'the Site) to:
Invite another user for a contract (Relationship or Activity, same as the follow)
Chat with users who already have a contract
Create a contract
Create a contract with agreement template
Edit a contract
Collaboratively edit a contract with the other PT owner
Accept, pending or decline a contract invitation
Suspend the contract for an emergency situation
Ask for arbitration
When a user has a need to discuss a relationship with their partner, they can invite them to join ReUnion to pair with them. If their partner accepts the pairing, a CS-1 Relationship contract is created. If the user already has a Relationship with this partner, they can also choose to change the unilateral contract into a bilateral one. They can edit the Relationship together, with agreement temples offered by ReUnion if they wish, create Activities under the Relationship, and receive symbolic PTs for their exchanges. Although the system provides chatting and co-editing functions, it strongly recommends engaging in person-to-person conversations before sending out invitations and beginning the relationship-editing process.
If the two people want to create a mutual fund for their Relationship, and accumulate monetized PTs for their exchanges, they can turn the CS-1 Relationship into a CS-2 one by putting monetized PTs into the contract. The monetized PTs will be composed into CCs, which can only be spent by the PT owners together[24]. As a Relationship become a CS-2, all PTs that generates from the Activities are monetized and be composed into CCs.
After one year of a CS-2 contract is fulfilled for one year, the PT owners are eligible to apply to turn the contract into CS-3. In addition to the money the PT owners invested in at least the past year, they also need to go through Proof-of-Relations to become a CS-3. When a contract becomes a CS-3, the generated PTs (and the CCs they will be composing) from then will be at least partially subsidized by the government.
Emergency Suspension, Arbitration, and Intervention
Emergency suspension is a mechanism for people who are inside of, or in proximity to, a relationship who may have a more in-depth understanding of the context and the history of the relationship. This requirement considers the suspension will have a substantial impact on the contract validity and will be followed by a series of arbitrations that the PT owners have to be involved; therefore, not anyone should be able to suspend a contract. However, we are aware that sometimes people from a distance might be easier to notice unfair situation happens, while people in close relations may be too familiarized to report the situation. A proper mechanism, similar to “see something, say something”, will be explored in the future.
A contract is usually locked and must be fulfilled until it reaches a Checkpoint. However, some instances allow for an emergency suspension of the contract, such as violence or excessive breaches of an agreement. Once an emergency is reported, a contract will be suspended and ReUnion will connect the associated parties to a third person from their shared network (if applicable); an external local body for arbitration; or, if necessary, a law enforcement official. After a set period, if both parties in the contract have not yet reached a consensus to revise or extend the contract, the system application will terminate the contract.
Identity and Eligibility Authentication
Identity authentication is necessary for certain relational contracts, especially for those related to sharing the care work for a third person who has little agency, such as a child or a mentally ill person. The users who wish to share third-person care work must prove that they have the right to do so. There will also be limitations and protections for users. For example, contracts that resemble a marital relationship will not be allowed to be created with a child[25].
Difference between Relationship and Activity
The differences between Relationship and Activity are philosophical and technological. A Relationship includes an overall description about two people’s relationship, it may include content like how they understand the nature of the relationship, their expectations, what kind of role they hope or want each other to be, where they want to arrive together within the Checkpoint, and so on. It is long-term (minimal of one-year), not task-oriented, and recommended to be written in ways that allow enough margin of error. An Activity, on the other hand, is task-oriented, has no duration requirement (but short-term in principle), and recommend to be relatively specific. An Activity exists under a Relationship that shares the same PT owners.
Relationship
Activity
overall description about two people’s relationship
events happens within the relationship
co-written
usually one request to another
long-term (minimal of one-year)
short-term in principle
non task-oriented
task oriented
encourage to allow a good margin of error
recommend to be relatively specific
Contract Stages
All contracts, both Relationship and Activity, have three contract stages that entail different levels of rights, risks, and responsibilities.
CS-1, First Contract Stage refers to a stage that is practically risk-free in a unilateral case. Users do not hold any liability in creating a CS-1 contract, and the contract does not cause any financial effect except for the users' internal reflection. CS-1 is able to receive non-monetary PTs for it, as a recognition by the system. In a bilateral case, on the other hand, it has the liability of civic agreement, but as CS-1 cannot be associated with money, the risk of the contract is non-financial. A user can create an unlimited amount of CS-2 contract, but they may be bound by the burnout notice as too little time left in their Self-Relationship.
CS-2, Second Contract Stage refers to a stage in which works as a civic contract when two PT owners commit to each other, and a shared wallet in which the two invest their own money (by monetizing PTs) into a micro-fund (as CCs) for the commitment. As a contract stage exists between CS-1 and CS-3, this contract stage allows as much exploration and experimentation as possible between two committed people. When a PT owner committed to a CS-2, they have the obligation to participate Proof-of-Relations, upon request by the other PT owner of their CS-2 contract. Any two people can create an unlimited amount of CS-2 contracts, but they may be bound by the cost of monetizing PTs, the load of work that each contract entails, and triggering burnout notice as too little time left in their Self-Relationship.
CS-3, Third Contract Stage refers to a stage in which the contract is recognized by (at least) the local government and being able to receive welfare. All CS-3 contracts can only be created by an application based on a CS-2 that is fulfilled for the year before the application of CS-3. All CS-3 must go through Proof-of Relations to be able to apply. A PT owner of a CS-3 contract has the obligation to participate in Proof-of-Relations, when the other PT owner is needed for their other Relationships. The amount of CS-3 that each user can apply is limited by government policy.
Contract Stages
CS-1
CS-2
CS-3
Liability
risk-free in a unilateral case
civic agreement liability
civic agreement liability
(non-financial) civic agreement liability in a bilateral case
financial investment in monetizing PTs
financial investment in monetizing PTs
liable to welfare policy of the associated government
Associated Tokens
receive PTs
compose CCs through monetized PTs from the contracted users
receive welfare via CCs; associated PTs will be monetized upon finished activities.
Amount limits
bounded by burnout notice
bounded by burnout notice
bounded by burnout notice
bounded by workloads
apply based on one-year fulfillment of a CS-2
bounded by the cost of monetizing PTs
bounded by invested workloads of CS-2 and future workloads
bounded by the total cost of one-year CS-2 fulfillment
bounded by Proof-of-Relations
total contract amount per user is limited by the policy of associated government
Community obligations
not obligated
obligated to Proof-of-Relations
obligated to Proof-of-Relations
Last updated