Identity and Access Patterns

Access control in a knowledge base serves two purposes that are often conflated: confidentiality (preventing unauthorized readers) and quality (preventing unqualified writers). Most access systems handle confidentiality adequately and handle quality poorly. The result: anyone can publish to the knowledge base, content quality degrades, users stop trusting it, and usage drops. The quality control problem is structural, not a user behavior problem.

1. Read Permissions Default should be: all authenticated employees can read all non-sensitive content. The most common access control mistake is over-restricting reads. When content is too hard to access, users bypass the knowledge base for ad hoc Slack questions — and the knowledge stays ephemeral. Reserve read restrictions for genuinely sensitive content: unreleased product roadmaps, compensation information, customer-specific data. Do not restrict reads because of organizational politics.
2. Write Permissions Separate authoring roles from publishing roles. All authenticated employees should be able to draft content. Publishing — making content visible to readers — should require either a designated contributor role or a review approval. This is not bureaucracy; it is the mechanism that maintains content quality as contributor count grows. A knowledge base where anyone can publish immediately is one where an employee's first-draft, unreviewed attempt becomes the authoritative source.
3. Review and Publish Permissions Reviewers are domain-qualified contributors who can approve content within their domain. Publishers in some systems are a separate role that handles the mechanical publish step after review approval. Define who qualifies as a reviewer for each domain — not "anyone with manager title" but "anyone with 6 months of direct experience in this area." Document the criteria. Undocumented reviewer qualification leads to either under-review (anyone is a reviewer) or over-restriction (only the knowledge team reviews).
4. Deprecation and Archive Permissions Deprecating and archiving content requires elevated permission — not because it is dangerous, but because it is irreversible in its effect on active users. A contributor who deprecates a widely-used runbook without a replacement is causing an availability problem. Require either the content owner's approval or a governance review for deprecation of content above a usage threshold (e.g., content accessed more than 20 times in the last 30 days).

# Knowledge base access control model
roles:
  reader:
    description: "All authenticated employees"
    permissions:
      - read: all non-restricted content
      - search: full corpus
      - export: own reads for personal use
    assignment: auto-assigned on authentication

  contributor:
    description: "Employees who submit content for review"
    permissions:
      - read: all non-restricted content
      - create: drafts in any category they are qualified for
      - edit: own drafts pre-publication
      - submit_for_review: own drafts
    assignment: self-service request, manager approval

  domain_reviewer:
    description: "Qualified to approve content within a specific domain"
    permissions:
      - all contributor permissions
      - review_and_approve: content in assigned domains only
      - request_revision: content in assigned domains
      - flag_for_deprecation: content in assigned domains
    assignment: domain lead nomination, knowledge team approval

  knowledge_steward:
    description: "Knowledge governance owner for a topic area"
    permissions:
      - all domain_reviewer permissions
      - deprecate: any content in assigned topic area
      - archive: deprecated content after 90-day window
      - manage_taxonomy: within assigned topic area
    assignment: formal role appointment, documented

  knowledge_admin:
    description: "Platform administration and cross-cutting governance"
    permissions:
      - all steward permissions across all topic areas
      - platform_configuration
      - access_management
      - analytics_full_access
    assignment: explicit appointment, minimal headcount (1–3 people)