--- a/Allura/docs/guides/permissions.rst
+++ b/Allura/docs/guides/permissions.rst
@@ -4,23 +4,22 @@
 User/Group model
 ---------------------------------------------------------------------
 
-In the allura system `users` can be assigned to various `groups` or 
+In the allura system `users` can be assigned to various `groups` or
 roles on a per-project basis.
 
-Users can be members of many groups, and both `users` and `groups` can 
-be assigned a list of `permissions` like `add_subproject`, 
-`commit_to_master` or `admin_users`.   Tools can define their own
-set of permissions, for their artifacts.   Tools are encouraged to
-prefix their permissions with the tool name, so for a tool called
-"tracker" a good permission name would be `tracker_edit_ticket`.
+Users can be members of many groups, and `groups` can
+be assigned a list of `permissions` like `edit`,
+`mdoderate` or `read`.   Tools can define their own
+set of permissions, for their artifacts.
 
-Individual artifacts and ACL's 
+Individual artifacts and ACL's
 ---------------------------------------------------------------------
 
-There are also likely to be some permissions that you want to assign
-to particular people or roles for a particular `Artifact` such as 
-a particular bug in the ticket tracker.   Allura supports this via
-an ACL field on every `Artifact` instance. 
+You may want to assign a permission
+to particular people or roles for a specific `Artifact` such as
+one bug in the ticket tracker.  The Allura platform supports this via
+an additive ACL field on every `Artifact` instance.  It is not exposed
+via the UI currently.
 
 Permission hierarchy
 --------------------------------------------------------------------
@@ -28,20 +27,17 @@
 Projects and subprojects can define user groups, but for any particular
 subproject the set of groups the user belongs to is additive.  This follows
 the basic principle that sub-project permissions and artifact permissions
-can *allow* additional access, but can't *restrict* it beyond 
-what permissions are allowed by a higher level project. 
+can *allow* additional access, but can't *restrict* it beyond
+what permissions are allowed by a higher level project.
 
 Permission predicates
 ---------------------------------------------------------------------
 
-Predicates are simple functions, several of which are defined in Allura 
+Predicates are simple functions, several of which are defined in Allura
 itself, and which can be added by any tool, which return true if
-permission is granted, and false if it is not. 
+permission is granted, and false if it is not.
 
 An example predicate function `has_project_access` takes two params, an object
-and a `permission` string.  It then checks to see if the current user 
-(picked up from the environment) has permission to perform that action on 
-that object, following the rules above. 
-
-
-
+and a `permission` string.  It then checks to see if the current user
+(picked up from the environment) has permission to perform that action on
+that object, following the rules above.