diff --git a/Client-server-discovery-lifecycle.md b/Client-server-discovery-lifecycle.md
index 0993b45..389b12b 100644
--- a/Client-server-discovery-lifecycle.md
+++ b/Client-server-discovery-lifecycle.md
@@ -86,6 +86,12 @@ Here's a more concrete proposal of how launching a server would work.  However,
    restoring any state they need on the server upon reconnect.
 4. The sbt server needs to outlive the original client that requested it, and only shut down when it has
    no more clients.
+5. The lock file location uniquely identifies the type of server launched.  Only one server per lock-file.
+   The launcher makes no assumptions about semantic meaning across launch configurations.  Only the
+   lock file.
+6. The protocol exposed by any server MUST be HTTP.   While the URI returned may allow users to negotiate,
+   making a HEAD request against the returned URI is guaranteed to succeed and becomes the mechanism of
+   pinging a server for "up".
 
 
 So, first We create a new interface for the sbt launcher, called `xsbt.ServerMain`:
@@ -95,7 +101,6 @@ package xsbti;
 
 public interface ServerMain {
   public java.net.URI start(AppConfiguration configuration);
-  public boolean isAlive(java.net.URI active);
 }
 ```
 
@@ -128,7 +133,7 @@ This is done via a new configuration similar to AppConfiguration, only with an a
   components: xsbti,extra
   cross-versioned: false
   resources: ${sbt.extraClasspath-}
-  lock: .active.properties
+  lock: ${cwd}/.sbtserver/active.properties
 
 [repositories]
   local
@@ -160,7 +165,7 @@ This will return the URI of an active launched server.  It will use the below ps
 ```scala
 def serviceLocator(config: ServerConfiguration, launcher: Launcher): URI = {
   def isReachable(info: URI): Boolean =
-     launcher.server(config).isAlive(info)
+     canMakeHeadRequest(info)
 
   withLockFile(config.lockFile) {
     readServerInfo(config.lockFile).filter(isReachable) match {