• Arbitrations
• Training
• Lesson12

Arbitration / Training

The Training Course for Case Managers and Arbitrators

Training Home / back

Lesson 12 - Arbitration - Precedents

What is a Precedent ?

A Precedent is a decision found in an earlier Arbitration case that can be used in recurring processes for future actions by CAcert people, or in new disputes that are filed into the forum.

• Wikipedia: In common law legal systems, a precedent or authority is a legal case establishing a principle or rule that a court or other judicial body utilizes when deciding subsequent cases with similar issues or facts. The general principle in common law legal systems is that similar cases should be decided so as to give similar and predictable outcomes, and the principle of precedent is the mechanism by which that goal is attained.

How does it affect CAcert in practice ?

Engineers [*] can apply a Precedent to a situation. Engineers need to be aware of the general scope and topics that are covered by existing Precedents affecting their team. Team Leaders can be consulted, and also the list below. Important Precedents will form part of the training.

If the subject matter appears close to the topic in a running situation, the Engineer can consult the ruling. Once Precedent is found that is on point, the process is the following

• Identify the facts as stated in the Precedent ruling.
• Compare those facts to the current situation that the Engineer faces.
• If the facts are the same exact match, or if in the judgement of the Engineer the facts are close enough to be reliable, the Engineer can apply the Execution.
• If the facts are not close enough, the Engineer may have to file a new dispute. In that dispute, a brief comment on the Precedents that are found to be close and interesting will be appreciated.
• When following the Precedent,
  • quote the ruling's number in any reports or documentation, and
  • follow any specific instructions on documentation found in the Precedent.

[*] Here, Engineers is used broadly to mean all CAcert people affected by a Precedent. Most Precedents will affect Support Engineers, Critical sysadms, Software Engineers, and Assurers, but the forum and any ruling is not limited to these people.

How does it affect Arbitration in practice ?

In CAcert, Precedents are primarily written to guide Engineers and save them the need to file disputes for routine issues. However, Precedents also guide future Arbitrations, and this is their more normal role in legal practice within the tradition of the English common law.

An Arbitrator needs to be aware of the general scope and topics that are covered by existing Precedents. At the simplest level, this can be achieved by scanning the list below. If the subject matter appears close to the topic in a running arbitration, the Arbitration can refer to the full ruling to clarify.

Once Precedent is found that is on point, the process is the following:

• Identify the facts as stated in the Precedent ruling.
• Find the facts in the current filed dispute.
• Compare these facts to the facts found in the current case.

  • If the facts are the same exact match, then the precedent is on point. Apply the Execution Steps. This may mean that the ruling directs Engineers to proceed.

  • If the facts are close, then the precedent is persuasive which is to say that it should be considered as an important principle and roadmap. At this point, an Arbitrator might have a choice of following the original Precedent as written, ignore it, or write a new Precedent that varies the results. Either way, the Arbitrator should document the choice made.

• write the Ruling, quoting the Precedent and outlining the approach taken.

How to make a Precedent Ruling

An Arbitrator identifies when a case may result in a Precedent.

• Identify a topic where a precedent ruling makes sense.
  • You may be asked to provide a precedent ruling by support or other teams where they have faced a persistent pattern of issues.

• Define a set of requirements called facts which identify when this ruling may be applied to a similar case without opening a new arbitration Case.

• Write the Execution in a manner that the Engineers can follow.
  • Define the actions which are justified if the requirements are met.
• Identify the Engineers (etc) who are affected. Target audience of execution orders can be:
  • Assurers (i.e. Name handling in Assurance)
  • Support Engineers (recurring support request, that can be handled through a procedure, to free up Arbitration queue, handled by SE's)
  • Software Engineers
  • Critical Sysadmins (i.e. Events scripted mailing execution)

• When you have finished a draft/proposal point, announce on the Arbitration mailing list that you are about to give a Precedent Ruling.

  • Ask for comments and assistance.
  • Allow some time for discussion. Although you are responsible for the ruling, please consider the arguments given! Once deep in an topic, it is easy to miss what others will know or see from outside.
• Follow-up.
  • Think about a history log. At least for statistic purposes a history log makes sense. Define what information has to be recorded in the history log.
  • Document the existence of the Precedent
    • For target audience who are affected -- contact the Team Leader, think about training.

    • For Arbitrators -- the list below, and on the Arbitration mailing list.

    • For Audit -- will the Auditor find it efficient to overview the issued Precedents, and consequence Executions?
    • For the Community -- is a blog post merited ?

Wider Considerations

An Arbitrator should think three times before deciding to issue a Precedent Ruling. As the ruling will then become the basis of many future actions, more care is needed. Others should be consulted on the likely ruling, before it comes into affect, as Engineers, Team Leaders and other Arbitrators may have a lot to offer.

The Precedent should be written from the point of view of the Engineer -- how easy is it to identify the Facts and the Execution? How easy is it to follow the steps? Does the Precedent assist the Engineer or hinder? Does the end result merit a Precedent, and does it meet the general Principles of the Community?

Complications and confusions may result in many errors, or the Precedent may simply not attract attention for lack of understanding.

What does a Precedent look like?

A clear Precedent case will deliver for future cases:

1. the facts applicable to this situation
2. the execution steps (that can be written in a procedure)
3. which parties the precedent affects (Support Engineers, Software Engineers, Critical sysadms, etc).

In addition, these things are useful:

1. A method for documenting the actions taken by the Engineer
2. A method for documenting all uses of the Precedent.

The Audit Problem: History Logging of cases handling for Audit purposes

• The default Arbitration case handling and reporting is through the CAcert Wiki system by individual pages for each case.
• Executions relying on prior Precedents do not have individual Arbitration case number as they are not filed as disputes.

  • u60: When a case is received through support, it gets a support ticket number. The initial arbitration case gets an Arbitration case number. The Arbitration case then closed. Further Support Tickets will be handled directly by a Support Engineer w/o moving this case into the Disputes queue. So the Support Engineer follows the ruling from the old case by adding the old Arbitration case number to the Support Ticket notes and by adding the new Support Ticket number to the old Arbitration case through the Post Arbitration log so a reference in both directions to the Support Ticket and to the Arbitration case exists. See Arbitrations/a20100210.2 as an example. This is to legalize and to keep track to the Support Engineers execution in further support cases regarding this case.

• Each later Execution of the Precedent needs to be identified with the Precedent's case number by the Engineer.

  • BernhardFröhlich: I anticipate a misunderstanding here. From context I'd say that the term "Precedent Case" in this paragraph wants to describe a support action which refers to a Precedence Arbitration Case as authorisation. Maybe some other term like "Follow up case" should be used

  • Iang: I've used the term Execution above, because it fits with the creation of the procedure. I think "Follow up case" is a bit indistinct, as case implies a filed case. There may be other terms...

• The Precedent ruling is recorded in the Precedent Arbitration case page
• The following Executions handled under this Precedent are not recorded within the Arbitration system automatically.
• So therefore, the recording of execution actions should be added to the Precedent's Wiki page

• In case of the recurring Events scripts mailings, each executed mailing is added as After Arbitration Ruling note at the bottom of the Precedent's Wiki page.

• Proposal: A log may be created in its own page under Arbitrations/Audit/<Precedence Case Number>, with categories CategoryAudit and CategoryArbitration (plus its own category?). This also allows setting special access rights, so SE's do not necessarily need write access to Arbitration Cases.

Known Precedents Cases

• G	a20090525.1	Event officer request recurrent notification to assurers near the location of the following ATEs - Precedent Case
  A	a20090618.12	User not registered under full name. Ruling accepts a common short name in the account. - Precedents Case
  A	a20090618.13	User name is written in all lower-case (case-sensitive/case-insensitive) - Precedents Case
  S	a20100210.2	Birthdate error (with assurance points). Revoke assurance 24 hours / 3 days / 7 days after an event - Precedents Case
  S	a20100407.1	Password Reset Procedure w/ Assurers - Precedents Case
  S	a20110119.1	Changing transliteration (diacritics) in my first name (Lukasz K) - Precedents Case
  S	a20100227.1	Small modification in username + Account Cleanup (Dirk R) - Precedents Case
  S	a20110213.1	Correction first/last-name swap (Rudy J) - Precedents Case
  S	a20110330.1	Name Change after Marriage w/ Assurance (Markus M) - Precedents Case
  A	a20100302.1	Givenname with Hyphen, 2nd givenname missing - Precedents Case
  S	a20110610.1	Removal of suffix - Precedents Case
  G	a20110608.1	Scripted Mailing to Organisation contacts
  S	a20111204.3	Minor account data differences which may be handled by SE - Precedents Case
  S	a20120126.1	Please add my full middlename to my account - Precedents Case
  S	a20101025.1	Removal of posts from mailing list archives
  A	a20120115.2	User account name doesn't match documentation - Precedents Case
  S	a20141024.1	Terminate account - Precedents Case
  S	a20140118.1	Need for precedent case how to handle tickets of a deceased person - Precedents Case
  S	a20140327.1	Request to revoke Assurance because of mistake in location and date - Precedents Case

• Legend: to handle by ....

  A	Arbitration, Assurance: This type of precedent case are precedent for Assurers. Arbitrators can follow this precedent ruling in a new case. New cases has to move to arbitration. Its likely that the new arbitrator references the new case to the existing precedent case
  G	Generic authorisations for other Areas (Events, Org Assurance)
  S	A dispute filing request, that can be handled by Support-Engineers w/o moving to arbitration

The following two prior precedents cases were made deprecated by a20141024.1, which is a follow up ruling that covers all kinds of delete account cases, now, while the two below only covered special cases:

• S	a20111128.3	Delete Account cases which may be handled by SE - No Assurances given, no certs or certs expired - Precedents Case
  S	a20140713.1	Delete assurer account with all assurances older than 7 years - Precedents Case

Questions