Protocol - Revision history

Seaborn: Removing obsolete 'store' section

2023-10-08T20:06:24Z

Removing obsolete 'store' section

2016-03-18T21:58:41Z

‎Best Practices: Developing Protocol

2015-07-26T21:03:52Z

‎Common Honorifics

2015-01-31T21:59:35Z

‎Best Practices: Developing Protocol

2015-01-08T03:09:53Z

‎Best Practices: Developing Protocol

2015-01-08T02:57:48Z

‎Best Practices: Developing Protocol

2014-09-29T20:56:14Z

‎Introduction of Protocol

2014-08-22T20:21:14Z

‎Best Practices: Developing Protocol

2014-08-22T20:18:00Z

‎Best Practices: Developing Protocol

2014-08-20T18:49:40Z

‎Introduction of Protocol

← Older revision		Revision as of 20:06, 8 October 2023
Line 165:		Line 165:
	* Awareness that every move, answer and behavior is being carefully scrutinized and judged.		* Awareness that every move, answer and behavior is being carefully scrutinized and judged.

−	~~== Shop ==~~
−
−	~~{{#if:http://astore.amazon.com/bdsinf-20?_encoding=UTF8&node=24\|0\|1300\|center\|thin}}~~

	[[Category:Theory]][[Category:Power Exchange]][[Category:Slave Training]]		[[Category:Theory]][[Category:Power Exchange]][[Category:Slave Training]]

@@ Line 75: / Line 75: @@
 *able to be consistently maintained with little or preferably no Dominant maintenance.
-*noticed by the dominant when the protocol is not followed.
+*noticed by the dominant when the protocol is not followed, which creates a bother great enough to express openly.
 *practical or it will not see regular use.
 *assist with facilitating and enriching the s-type headspace and [[D/s]] relationship rather than detracting from them.

@@ Line 22: / Line 22: @@
 * Service/Pro Top/Bottom
-* Alpha slave/Kajira
+* Alpha slave/Kajira or Kajirus
 * Daddy/Mommy/Caregiver
 * Mentor

@@ Line 79: / Line 79: @@
 *assist with facilitating and enriching the s-type headspace and [[D/s]] relationship rather than detracting from them.
 *avoid boredom and preferably guard against it.
-*able to fall within [[RACK]] or [[SSC]] guidelines as well as [[negotiated]] limits.
+*be reasonably safe as well as within [[negotiated]] limits.
 *a statement of what to do rather than what not to do.
 *revisited early on and annually/as needed to ensure it is relevant and serving the intended purpose.

@@ Line 75: / Line 75: @@
 *able to be consistently maintained with little or preferably no Dominant maintenance.
-*is noticed by the dominant when the protocol is not followed.
+*noticed by the dominant when the protocol is not followed.
 *practical or it will not see regular use.
 *assist with facilitating and enriching the s-type headspace and [[D/s]] relationship rather than detracting from them.
 *avoid boredom and preferably guard against it.
 *able to fall within [[RACK]] or [[SSC]] guidelines as well as [[negotiated]] limits.
-*is a statement of what to do rather than what not to do.
+*a statement of what to do rather than what not to do.
 With that information you will be able to create your own rewarding protocols with your partner, provided you know what it is that you want and like, and if you don't, it's important to get to know yourself if you intend on directing your [[s-type]] in how to please you.

← Older revision		Revision as of 20:56, 29 September 2014
Line 112:		Line 112:

	Consider having them keep a log of when a protocol is first taught and when it is learned sufficiently to be set as an expectation so that the log may be referred to if there is a protocol breach. Keep your schema private from them at this time until such a time as it is no longer necessary.		Consider having them keep a log of when a protocol is first taught and when it is learned sufficiently to be set as an expectation so that the log may be referred to if there is a protocol breach. Keep your schema private from them at this time until such a time as it is no longer necessary.
		+
		+	If the slave finds that a protocol is not corrected when failed, the slave will often begin to have the relationship structure degrade in their mind which is poisonous to a relationship based on structure and power exchange. If this becomes common the structure can fail. If the Master finds they aren't upset enough to mention and appropriately deal with a protocol when the expectation isn't met, or worse, that it isn't noticed at all when the expectation isn't followed through on, it is best to consider downgrading the protocol to a stated preference rather than an expectation that must be met as is implied by using the term protocol.

	== High Protocol ==		== High Protocol ==

@@ Line 88: / Line 88: @@
 *[http://www.ownership-possession.com/wiki/Estate_protocol/ House Tanos Estate Protocols]
-*[http://www.elegantlykinky.com/#acf/custom_plain Mistress Zeneca's High Protocol Manuals]
+*[http://www.elegantlykinky.com/#high-protocol-manual Mistress Zeneca's High Protocol Manuals]
 *[https://docs.google.com/document/d/1AMiqYJ98mu-YXIVkp9lxNiKhfOuIr1_JeECMb6Ikw-E/ House of KAOS Estate Protocols]

@@ Line 85: / Line 85: @@
 Sometimes when developing your own protocols it can be useful to have a basis for comparison, take a look at some of these sources and note how very different they are in writing style, purpose and application.
 *[http://www.ownership-possession.com/wiki/Estate_protocol/ House Tanos Estate Protocols]
-*[http://www.amazon.com/Protocol-Handbook-Leather-Slave-Practice/dp/1887895159/ref=pd_bxgy_b_img_y Robert Ruebel's Protocol Handbook for the Leather Slave]
+*[http://www.elegantlykinky.com/#acf/custom_plain Mistress Zeneca's High Protocol Manuals]
-*[http://www.amazon.com/Protocols-Handbook-Robert-J-Rubel/dp/1887895124 Robert Ruebel's Protocol Handbook for the Female Slave]
+*[https://docs.google.com/document/d/1AMiqYJ98mu-YXIVkp9lxNiKhfOuIr1_JeECMb6Ikw-E/ House of KAOS Estate Protocols]
-−
-*[http://www.elegantlykinky.com/#acf/custom_plain Mistress Zeneca's High Protocol Manuals]
 === Protocol Schema ===

@@ Line 113: / Line 113: @@
 When introducing protocols, consider discussing them as well as the concerns and challenges that may arise with your s-type as they will have certain insights you will not, and require their feedback as they integrate protocols.
-usually introduce 1-3 at a time until the [[s-type]] has canonized them through [[conditioning]] and then add more of your protocols so as not to overburden your s-type with too many drastic changes at once such as by handing them a huge manual of protocols to be responsible for all at once.
+Introduce 1-3 at a time until the [[s-type]] has canonized them through [[conditioning]] and then add more of your protocols so as not to overburden your s-type with too many drastic changes at once such as by handing them a huge manual of protocols to be responsible for all at once.  When trying out a new protocol, use it on a trial basis, reassess and alter the new protocol as necessary so that it will best serve the relationship.  When the process is refined, agreed upon and trained, dedicate it to the protocols that are considered expectations of the [[d-type]].
 Consider having them keep a log of when a protocol is first taught and when it is learned sufficiently to be set as an expectation so that the log may be referred to if there is a protocol breach.  Keep your schema private from them at this time until such a time as it is no longer necessary.