Update contrib docs headers to sentence case (#29276)

2026-04-21 13:37:30 +00:00 · 2025-05-20 11:26:35 -05:00 · 2025-05-20 11:26:35 -05:00 · 030c61ca17
commit 030c61ca17
parent a2a66af6e4
24 changed files with 125 additions and 125 deletions
--- a/docs/Contributing/README.md
+++ b/docs/Contributing/README.md
@ -2,7 +2,7 @@

 Welcome to the Fleet contributor documentation! This documentation is designed to help you contribute to the Fleet project.

-## Documentation Structure
+## Documentation structure

 The documentation is organized into the following sections:

@ -16,7 +16,7 @@ The documentation is organized into the following sections:
 - [Research](research/) - Research documents for product groups
 - [Responsibilities](responsibilities/) - Responsibility documents for product groups

-## Product Groups
+## Product groups

 Fleet is organized into three main product groups:

--- a/docs/Contributing/adr/README.md
+++ b/docs/Contributing/adr/README.md
@ -14,7 +14,7 @@ ADRs help teams:
 - Onboard new team members by providing context
 - Track the evolution of the system architecture over time

-## ADR Format
+## ADR format

 Each ADR follows a standard format:

@ -25,7 +25,7 @@ Each ADR follows a standard format:
 5. **Consequences**: The consequences of the decision, both positive and negative
 6. **References**: Any references to related documents or resources

-## Creating a New ADR
+## Creating a new ADR

 To create a new ADR:

@ -33,7 +33,7 @@ To create a new ADR:
 2. Fill in the template with your decision
 3. Submit a pull request with your new ADR

-## ADR Index
+## ADR index

 <!-- Add new ADRs to this list -->

--- a/docs/Contributing/adr/template.md
+++ b/docs/Contributing/adr/template.md
@ -32,7 +32,7 @@ Describe the consequences of the decision, both positive and negative. This shou
 - Impact on existing systems or processes
 - Future considerations or follow-up decisions needed

-## Alternatives Considered
+## Alternatives considered

 Describe alternative solutions that were considered and why they were not chosen.

--- a/docs/Contributing/architecture/README.md
+++ b/docs/Contributing/architecture/README.md
@ -7,7 +7,7 @@ This directory contains high-level architecture documentation for Fleet.
 - [High-Level Architecture](high-level-architecture.md) - Overview of Fleet's architecture
 - [Infrastructure](infrastructure.md) - Documentation on Fleet's infrastructure

-## Product Group Architecture
+## Product group architecture

 Each product group has its own architecture documentation:

--- a/docs/Contributing/architecture/high-level-architecture.md
+++ b/docs/Contributing/architecture/high-level-architecture.md
@ -1,7 +1,7 @@
 # High level architecture

 - [Overview](#overview)
- [Main System Components](#main-system-components)
+- [Main system components](#main-system-components)

 ## Overview

@ -32,7 +32,7 @@ At a high level, Fleet consists of:

 The diagrams below illustrate how these components interact and the data flow for different operations like live queries, scheduled queries, and vulnerability management.

-## Main System Components
+## Main system components

 ```mermaid
 graph LR;
@ -104,7 +104,7 @@ graph LR;



-## The path of Live Query
+## The path of live query

 ### 1 - Fleet User initiates the query
 ```mermaid
@ -145,7 +145,7 @@ graph LR;

 ```

-## The path of a scheduled Query
+## The path of a scheduled query

 ### 1 - Fleet User initiates the query
 ```mermaid
--- a/docs/Contributing/architecture/mdm/README.md
+++ b/docs/Contributing/architecture/mdm/README.md
@ -15,7 +15,7 @@ Fleet's MDM architecture is designed to manage devices across different platform
 - [Disk Encryption](disk-encryption.md) - Architecture for disk encryption
 - [Automated Device Enrollment](automated-device-enrollment.md) - Architecture for automated device enrollment

-## Related Resources
+## Related resources

 - [MDM Product Group Documentation](../../product-groups/mdm/) - Documentation for the MDM product group
 - [MDM Development Guides](../../guides/mdm/) - Guides for MDM development
--- a/docs/Contributing/architecture/mdm/apple-mdm-architecture.md
+++ b/docs/Contributing/architecture/mdm/apple-mdm-architecture.md
@ -1,4 +1,4 @@
-# Apple MDM Architecture
+# Apple MDM architecture

 This document provides an overview of Fleet's Apple Mobile Device Management (MDM) architecture.

--- a/docs/Contributing/architecture/mdm/automated-device-enrollment.md
+++ b/docs/Contributing/architecture/mdm/automated-device-enrollment.md
@ -1,4 +1,4 @@
-# Automated Device Enrollment Architecture
+# Automated Device Enrollment architecture

 This document provides an overview of Fleet's Automated Device Enrollment (ADE) architecture for MDM.

@ -6,26 +6,26 @@ This document provides an overview of Fleet's Automated Device Enrollment (ADE)

 Automated Device Enrollment (ADE) in Fleet's MDM allows for zero-touch deployment of devices, enabling organizations to automatically enroll and configure devices without manual intervention. This document provides insights into the design decisions, system components, and interactions specific to the ADE functionality.

-## Architecture Overview
+## Architecture overview

 The ADE architecture integrates with platform-specific enrollment programs (Apple Business Manager/Apple School Manager for Apple devices) to automatically enroll devices when they are activated.

-## Key Components
+## Key components

 - **Enrollment Program Integration**: Integration with platform-specific enrollment programs.
 - **Device Assignment**: Mapping between devices and enrollment configurations.
 - **Enrollment Profiles**: Configurations applied during the enrollment process.
 - **Synchronization**: Mechanisms to synchronize device information with enrollment programs.

-## Architecture Diagram
+## Architecture diagram

 ```
 [Placeholder for Automated Device Enrollment Architecture Diagram]
 ```

-## Platform-Specific Implementation
+## Platform-specific implementation

-### Apple Automated Device Enrollment
+### Apple automated device enrollment

 For Apple devices, ADE (formerly known as DEP) involves the following components:

@ -34,7 +34,7 @@ For Apple devices, ADE (formerly known as DEP) involves the following components
 - **Enrollment Profiles**: Configurations that define the enrollment experience.
 - **Device Assignments**: Mapping between devices and enrollment profiles.

-#### Synchronization Process
+#### Synchronization process

 Synchronization of devices from all ABM tokens uploaded to Fleet happens in the `dep_syncer` cron job, which runs every 1 minute.

@ -47,11 +47,11 @@ On every run, we pull the list of added/modified/deleted devices and:
   - Always assign a JSON profile for added devices. We assign JSON profile for modified devices if the profile has not been modified according to Apple DEP device response.
 2. If the host was deleted, we soft delete the `host_dep_assignments` entry.

-#### Special Case: Host in ABM is Deleted in Fleet
+#### Special case: Host in ABM is deleted in Fleet

 If an IT admin deletes a host in the UI/API, and we have a non-deleted entry in `host_dep_assignments` for the host, we immediately create a new host entry as if the device was just ingested from the ABM sync.

-## Related Resources
+## Related resources

 - [MDM Product Group Documentation](../../product-groups/mdm/) - Documentation for the MDM product group
 - [MDM Development Guides](../../guides/mdm/) - Guides for MDM development
--- a/docs/Contributing/architecture/mdm/disk-encryption.md
+++ b/docs/Contributing/architecture/mdm/disk-encryption.md
@ -1,4 +1,4 @@
-# Disk Encryption Architecture
+# Disk encryption architecture

 This document provides an overview of Fleet's Disk Encryption architecture for MDM.

@ -6,24 +6,24 @@ This document provides an overview of Fleet's Disk Encryption architecture for M

 Disk Encryption in Fleet's MDM allows for securing device data by encrypting the storage media. This document provides insights into the design decisions, system components, and interactions specific to the Disk Encryption functionality.

-## Architecture Overview
+## Architecture overview

 The Disk Encryption architecture leverages platform-specific encryption technologies (FileVault for macOS, BitLocker for Windows, LUKS via LVM for Linux) to encrypt device storage and securely manage recovery keys.

-## Key Components
+## Key components

 - **Encryption Configuration**: Settings and policies for configuring disk encryption.
 - **Key Management**: Secure storage and retrieval of encryption keys.
 - **Verification**: Mechanisms to verify the encryption status of devices.
 - **Recovery**: Processes for recovering access to encrypted devices.

-## Architecture Diagram
+## Architecture diagram

 ```
 [Placeholder for Disk Encryption Architecture Diagram]
 ```

-## Platform-Specific Implementation
+## Platform-specific implementation

 ### FileVault (macOS)

@ -51,11 +51,11 @@ When disk encryption is enabled, the server sends a notification to orbit, who c

 After the disk is encrypted, orbit sends the key back to the server using an orbit-authenticated endpoint (`POST /api/fleet/orbit/disk_encryption_key`).

-## Key Storage and Security
+## Key storage and security

 Encryption keys are stored in the `host_disk_encryption_keys` table. The value for the key is encrypted using Fleet's CA certificate, and thus can only be decrypted if you have the CA private key.

-## Related Resources
+## Related resources

 - [MDM Product Group Documentation](../../product-groups/mdm/) - Documentation for the MDM product group
 - [MDM Development Guides](../../guides/mdm/) - Guides for MDM development
--- a/docs/Contributing/architecture/mdm/end-user-authentication.md
+++ b/docs/Contributing/architecture/mdm/end-user-authentication.md
@ -1,4 +1,4 @@
-# End User Authentication Architecture
+# End user authentication architecture

 This document provides an overview of Fleet's End User Authentication architecture for MDM.

@ -6,25 +6,25 @@ This document provides an overview of Fleet's End User Authentication architectu

 End User Authentication in Fleet's MDM allows for associating managed devices with specific users, enabling user-based policies and personalized device management. This document provides insights into the design decisions, system components, and interactions specific to the End User Authentication functionality.

-## Architecture Overview
+## Architecture overview

 The End User Authentication architecture integrates with identity providers (IdPs) to authenticate users and associate them with their devices. This enables user-specific policies and configurations to be applied to devices.

-## Key Components
+## Key components

 - **Identity Provider Integration**: Integration with external identity providers such as Okta, Azure AD, and Google Workspace.
 - **User-Device Association**: Mapping between users and their devices.
 - **Authentication Flow**: The process by which users authenticate and are associated with their devices.

-## Architecture Diagram
+## Architecture diagram

 ```
 [Placeholder for End User Authentication Architecture Diagram]
 ```

-## Authentication Flows
+## Authentication flows

-### Automated Authentication
+### Automated authentication

 1. New device starts the enrollment process and is prompted to login to the IDP.
 2. Fleet captures the username and stores it to register after enrollment.
@ -32,20 +32,20 @@ The End User Authentication architecture integrates with identity providers (IdP
 4. Optionally MDM server maps user information to SCIM data already sent by IdP.
 5. MDM server associates the user with the device.

-## Identity Provider Integration
+## Identity provider integration

 Fleet integrates with various identity providers to authenticate users:

 - **SAML**: For integration with SAML-based identity providers such as Okta and Azure AD.

-## User-Device Association
+## User-device association

 User-device association is stored in the Fleet database and is used to apply user-specific policies and configurations to devices. The association can be established through:

 - **Directory Integration**: When user information is retrieved from a directory service.
 - **Automated Authentication**: When a user enrolls in MDM after authenticating with an IDP.

-## Related Resources
+## Related resources

 - [MDM Product Group Documentation](../../product-groups/mdm/) - Documentation for the MDM product group
 - [MDM Development Guides](../../guides/mdm/) - Guides for MDM development
--- a/docs/Contributing/architecture/mdm/mdm-overview.md
+++ b/docs/Contributing/architecture/mdm/mdm-overview.md
@ -1,4 +1,4 @@
-# MDM Architecture Overview
+# MDM architecture overview

 This document provides an overview of Fleet's Mobile Device Management (MDM) architecture.

@ -6,7 +6,7 @@ This document provides an overview of Fleet's Mobile Device Management (MDM) arc

 Fleet's MDM architecture is designed to manage devices across different platforms, including Apple (macOS, iOS) and Windows. This document provides insights into the design decisions, system components, and interactions specific to the MDM functionality.

-## System Components
+## System components

 The MDM architecture consists of the following main components:

@ -16,13 +16,13 @@ The MDM architecture consists of the following main components:
 - **Commands**: Instructions sent to devices to perform specific actions.
 - **Device Communication**: The protocols and mechanisms used for communication between the MDM server and devices.

-## Architecture Diagram
+## Architecture diagram

 ```
 [Placeholder for MDM Architecture Diagram]
 ```

-## Integration Points
+## Integration points

 The MDM architecture integrates with the following components:

@ -31,7 +31,7 @@ The MDM architecture integrates with the following components:
 - **Authentication Systems**: For user and device authentication.
 - **Certificate Authorities**: For issuing and managing device certificates.

-## Platform-Specific Considerations
+## Platform-specific considerations

 ### Apple MDM

@ -41,7 +41,7 @@ See [Apple MDM Architecture](apple-mdm-architecture.md) for details on Apple-spe

 See [Windows MDM Architecture](windows-mdm-architecture.md) for details on Windows-specific MDM architecture.

-## Related Resources
+## Related resources

 - [MDM Product Group Documentation](../../product-groups/mdm/) - Documentation for the MDM product group
 - [MDM Development Guides](../../guides/mdm/) - Guides for MDM development
--- a/docs/Contributing/architecture/mdm/windows-mdm-architecture.md
+++ b/docs/Contributing/architecture/mdm/windows-mdm-architecture.md
@ -1,4 +1,4 @@
-# Windows MDM Architecture
+# Windows MDM architecture

 This document provides an overview of Fleet's Windows Mobile Device Management (MDM) architecture.

@ -6,32 +6,32 @@ This document provides an overview of Fleet's Windows Mobile Device Management (

 Fleet's Windows MDM architecture is designed to manage Windows devices. This document provides insights into the design decisions, system components, and interactions specific to the Windows MDM functionality.

-## Windows MDM Protocol
+## Windows MDM protocol

 Windows MDM is based on the OMA Device Management (OMA-DM) protocol and uses SyncML for data exchange. Microsoft has extended the protocol with Windows-specific features and capabilities.

-### Key Components
+### Key components

 - **MDM Enrollment**: The process by which devices are registered with the MDM server.
 - **MDM Sync**: The process by which devices communicate with the MDM server.
 - **Configuration Service Providers (CSPs)**: Components that provide an interface to device settings.
 - **MDM Policies**: Settings and configurations applied to managed devices.

-## Architecture Diagram
+## Architecture diagram

 ```
 [Placeholder for Windows MDM Architecture Diagram]
 ```

-## Enrollment Flows
+## Enrollment flows

-### User-Initiated Enrollment
+### User-initiated enrollment

 1. User downloads and installs the enrollment package.
 2. Device enrolls with the MDM server.
 3. MDM server sends initial configuration profiles.

-### Azure AD Join
+### Azure AD join

 1. Device is joined to Azure AD.
 2. Device automatically enrolls with the MDM server.
@ -47,7 +47,7 @@ Common CSPs used by Fleet include:
 - **DeviceStatus CSP**: For retrieving device status information.
 - **WindowsUpdatePolicy CSP**: For configuring Windows Update settings.

-## SyncML Structure
+## SyncML structure

 Windows MDM uses SyncML for communication between the device and the MDM server. A typical SyncML message includes:

@ -55,7 +55,7 @@ Windows MDM uses SyncML for communication between the device and the MDM server.
 - **Body**: Contains commands and data.
 - **Status**: Contains the result of previous commands.

-## Related Resources
+## Related resources

 - [MDM Product Group Documentation](../../product-groups/mdm/) - Documentation for the MDM product group
 - [MDM Development Guides](../../guides/mdm/) - Guides for MDM development
--- a/docs/Contributing/architecture/orchestration/README.md
+++ b/docs/Contributing/architecture/orchestration/README.md
@ -1,4 +1,4 @@
-# Orchestration Architecture
+# Orchestration architecture

 This directory contains documentation about Fleet's Orchestration architecture.

@ -15,7 +15,7 @@ Fleet's Orchestration architecture is designed to manage and query devices at sc
 - [Host Vitals](host-vitals.md) - Architecture for host vitals
 - [Teams and Access Control](teams-and-access-control.md) - Architecture for teams and access control

-## Related Resources
+## Related resources

 - [Orchestration Product Group Documentation](../../product-groups/orchestration/) - Documentation for the Orchestration product group
 - [Orchestration Development Guides](../../guides/orchestration/) - Guides for Orchestration development
--- a/docs/Contributing/architecture/orchestration/host-vitals.md
+++ b/docs/Contributing/architecture/orchestration/host-vitals.md
@ -1,4 +1,4 @@
-# Host Vitals Architecture
+# Host vitals architecture

 This document provides an overview of Fleet's Host Vitals architecture.

@ -6,26 +6,26 @@ This document provides an overview of Fleet's Host Vitals architecture.

 Host Vitals in Fleet provide real-time and historical information about the health and status of devices, including CPU usage, memory usage, disk usage, and uptime. This document provides insights into the design decisions, system components, and interactions specific to the Host Vitals functionality.

-## Architecture Overview
+## Architecture overview

 The Host Vitals architecture enables the collection, processing, and visualization of device health metrics across a fleet of devices. It leverages osquery's capabilities to collect system metrics and Fleet's infrastructure to process and display them.

-## Key Components
+## Key components

 - **Metrics Collection**: The process of collecting system metrics from devices.
 - **Metrics Processing**: The processing of collected metrics for storage and analysis.
 - **Metrics Storage**: The storage of metrics for historical analysis.
 - **Metrics Visualization**: The display of metrics in the Fleet UI.

-## Architecture Diagram
+## Architecture diagram

 ```
 [Placeholder for Host Vitals Architecture Diagram]
 ```

-## Metrics Collection Flow
+## Metrics collection flow

-### 1 - Agent Collects Metrics
+### 1 - Agent collects metrics

 ```
 osquery agent -> Server
@ -34,7 +34,7 @@ osquery agent -> Server
 1. osquery agent collects system metrics using osquery tables.
 2. osquery agent sends the metrics to the Fleet server.

-### 2 - Server Processes and Stores Metrics
+### 2 - Server processes and stores metrics

 ```
 Server -> DB
@ -43,7 +43,7 @@ Server -> DB
 1. Server processes the received metrics.
 2. Server stores the metrics in the database.

-### 3 - UI Displays Metrics
+### 3 - UI displays metrics

 ```
 UI -> Server -> DB
@ -58,7 +58,7 @@ UI -> Server -> DB

 See the [host details API](https://fleetdm.com/docs/rest-api/rest-api#get-host) documentation for details on collected vitals.

-## Performance Considerations
+## Performance considerations

 Host Vitals collection can impact device and server performance, especially for large fleets. The following considerations should be taken into account:

@ -66,7 +66,7 @@ Host Vitals collection can impact device and server performance, especially for
 - **Metric Count**: Collecting more metrics can impact device and server performance.
 - **Fleet Size**: Collecting metrics from a large number of devices can impact server performance.

-## Related Resources
+## Related resources

 - [Host details API documentation](https://fleetdm.com/docs/rest-api/rest-api#get-host)
 - [Orchestration Product Group Documentation](../../product-groups/orchestration/) - Documentation for the Orchestration product group
--- a/docs/Contributing/architecture/orchestration/orchestration-overview.md
+++ b/docs/Contributing/architecture/orchestration/orchestration-overview.md
@ -1,4 +1,4 @@
-# Orchestration Architecture Overview
+# Orchestration architecture overview

 This document provides an overview of Fleet's Orchestration architecture.

@ -6,7 +6,7 @@ This document provides an overview of Fleet's Orchestration architecture.

 Fleet's Orchestration architecture is designed to manage and query devices at scale using osquery, providing visibility into device status, configuration, and security posture. This document provides insights into the design decisions, system components, and interactions specific to the Orchestration functionality.

-## System Components
+## System components

 The Orchestration architecture consists of the following main components:

@ -16,20 +16,20 @@ The Orchestration architecture consists of the following main components:
 - **Result Processing**: The component that processes and stores query results.
 - **Teams and Access Control**: The component that manages user access to devices and queries.

-## Architecture Diagram
+## Architecture diagram

 ```
 [Placeholder for Orchestration Architecture Diagram]
 ```

-## Query Types
+## Query types

 Fleet supports two main types of queries:

 - **Live Queries**: Ad-hoc queries that are executed in real-time and return results immediately.
 - **Scheduled Queries**: Queries that are executed on a schedule and store results for later analysis.

-### Live Queries
+### Live queries

 Live queries are executed in real-time and return results immediately. The process for executing a live query is as follows:

@ -39,7 +39,7 @@ Live queries are executed in real-time and return results immediately. The proce
 4. Devices execute the query and return results.
 5. Fleet server processes and displays the results.

-### Scheduled Queries
+### Scheduled queries

 Scheduled queries are executed on a schedule and store results for later analysis. The process for executing a scheduled query is as follows:

@ -50,7 +50,7 @@ Scheduled queries are executed on a schedule and store results for later analysi
 5. Devices return results to the Fleet server.
 6. Fleet server processes and stores the results.

-## Integration Points
+## Integration points

 The Orchestration architecture integrates with the following components:

@ -59,7 +59,7 @@ The Orchestration architecture integrates with the following components:
 - **Redis**: For storing live query results.
 - **External Logging Systems**: For storing query results for long-term analysis.

-## Related Resources
+## Related resources

 - [Orchestration Product Group Documentation](../../product-groups/orchestration/) - Documentation for the Orchestration product group
 - [Orchestration Development Guides](../../guides/orchestration/) - Guides for Orchestration development
--- a/docs/Contributing/architecture/orchestration/query-packs.md
+++ b/docs/Contributing/architecture/orchestration/query-packs.md
@ -1,4 +1,4 @@
-# Query Packs Architecture
+# Query packs architecture

 This document provides an overview of Fleet's Query Packs architecture.

@ -6,26 +6,26 @@ This document provides an overview of Fleet's Query Packs architecture.

 Query packs in Fleet allow users to group related queries together for easier management and distribution. This document provides insights into the design decisions, system components, and interactions specific to the Query Packs functionality.

-## Architecture Overview
+## Architecture overview

 The Query Packs architecture enables the organization, configuration, and distribution of groups of queries across a fleet of devices. It leverages osquery's pack capabilities to execute multiple queries on devices and return results to the Fleet server.

-## Key Components
+## Key components

 - **Pack Definition**: The definition of a pack, including the queries it contains and their schedules.
 - **Pack Distribution**: The mechanism for distributing packs to devices.
 - **Query Execution**: The process of executing queries within a pack.
 - **Result Collection**: The process of collecting and processing query results.

-## Architecture Diagram
+## Architecture diagram

 ```
 [Placeholder for Query Packs Architecture Diagram]
 ```

-## Pack Execution Flow
+## Pack execution flow

-### 1 - Fleet User Creates a Query Pack
+### 1 - Fleet user creates a query pack

 ```
 Fleet User -> API Client (Frontend or Fleetctl) -> Server -> DB
@ -34,7 +34,7 @@ Fleet User -> API Client (Frontend or Fleetctl) -> Server -> DB
 1. Fleet user creates a query pack for a team or globally through the UI or API.
 2. Server stores the pack configuration in the database.

-### 2 - Agent Gets Config File (with the Query Pack)
+### 2 - Agent gets config file (with the query pack)

 ```
 osquery agent -> Server -> DB
@ -44,7 +44,7 @@ osquery agent -> Server -> DB
 2. Server merges team and global configurations, including packs.
 3. Server returns the merged configuration to the agent.

-### 3 - Agent Executes Queries and Returns Results
+### 3 - Agent executes queries and returns results

 ```
 osquery agent -> Server -> Optional External Log
@ -54,7 +54,7 @@ osquery agent -> Server -> Optional External Log
 2. osquery agent sends the results to the server.
 3. Server optionally forwards the results to an external logging system.

-## Pack Configuration
+## Pack configuration

 Query packs have several configuration options:

@ -64,7 +64,7 @@ Query packs have several configuration options:
 - **Targets**: The devices or teams targeted by the pack.
 - **Schedules**: The schedules for each query in the pack.

-## Performance Considerations
+## Performance considerations

 Query packs can impact device performance, especially for packs with complex queries or queries that run frequently. The following considerations should be taken into account:

@ -72,7 +72,7 @@ Query packs can impact device performance, especially for packs with complex que
 - **Query Frequency**: Queries that run frequently can impact device performance.
 - **Pack Size**: Packs with many queries can impact device performance.

-## Related Resources
+## Related resources

 - [Orchestration Product Group Documentation](../../product-groups/orchestration/) - Documentation for the Orchestration product group
 - [Orchestration Development Guides](../../guides/orchestration/) - Guides for Orchestration development
--- a/docs/Contributing/architecture/orchestration/scheduled-queries.md
+++ b/docs/Contributing/architecture/orchestration/scheduled-queries.md
@ -1,4 +1,4 @@
-# Scheduled Queries Architecture
+# Scheduled queries architecture

 This document provides an overview of Fleet's Scheduled Queries architecture.

@ -6,26 +6,26 @@ This document provides an overview of Fleet's Scheduled Queries architecture.

 Scheduled queries in Fleet allow users to configure queries that run on a regular schedule, providing ongoing visibility into device status, configuration, and security posture. This document provides insights into the design decisions, system components, and interactions specific to the Scheduled Queries functionality.

-## Architecture Overview
+## Architecture overview

 The Scheduled Queries architecture enables the configuration, distribution, and execution of queries on a schedule across a fleet of devices. It leverages osquery's scheduled query capabilities to execute SQL queries on devices and return results to the Fleet server.

-## Key Components
+## Key components

 - **Query Configuration**: The definition of a query, including the SQL statement, schedule, and target devices.
 - **Configuration Distribution**: The mechanism for distributing query configurations to devices.
 - **Result Collection**: The process of collecting and processing query results.
 - **Result Storage**: The storage of query results for analysis and alerting.

-## Architecture Diagram
+## Architecture diagram

 ```
 [Placeholder for Scheduled Queries Architecture Diagram]
 ```

-## Query Execution Flow
+## Query execution flow

-### 1 - Fleet User Creates a Scheduled Query
+### 1 - Fleet user creates a scheduled query

 ```
 Fleet User -> API Client (Frontend or Fleetctl) -> Server -> DB
@ -34,7 +34,7 @@ Fleet User -> API Client (Frontend or Fleetctl) -> Server -> DB
 1. Fleet user creates a scheduled query for a team or globally through the UI or API.
 2. Server stores the query configuration in the database.

-### 2 - Agent Gets Config File (with the Scheduled Query)
+### 2 - Agent gets config file (with the scheduled query)

 ```
 osquery agent -> Server -> DB
@ -44,7 +44,7 @@ osquery agent -> Server -> DB
 2. Server merges team and global configurations.
 3. Server returns the merged configuration to the agent.

-### 3 - Agent Returns Results to be (Optionally) Logged
+### 3 - Agent returns results to be (optionally) logged

 ```
 osquery agent -> Server -> Optional External Log
@ -54,14 +54,14 @@ osquery agent -> Server -> Optional External Log
 2. osquery agent sends the results to the server.
 3. Server optionally forwards the results to an external logging system.

-## Configuration Options
+## Configuration options

 osquery agents have several configuration options that affect scheduled queries:

 1. **Config TLS Refresh**: The frequency at which the agent pulls down the configuration file (typically 10 seconds).
 2. **Logger TLS**: The frequency of sending query results (typically 10 seconds).

-## Performance Considerations
+## Performance considerations

 Scheduled queries can impact device performance, especially for complex queries or queries that run frequently. The following considerations should be taken into account:

@ -69,7 +69,7 @@ Scheduled queries can impact device performance, especially for complex queries
 - **Query Frequency**: Queries that run frequently can impact device performance.
 - **Result Size**: Large result sets can consume significant memory and network bandwidth.

-## Related Resources
+## Related resources

 - [Orchestration Product Group Documentation](../../product-groups/orchestration/) - Documentation for the Orchestration product group
 - [Orchestration Development Guides](../../guides/orchestration/) - Guides for Orchestration development
--- a/docs/Contributing/architecture/orchestration/teams-and-access-control.md
+++ b/docs/Contributing/architecture/orchestration/teams-and-access-control.md
@ -1,4 +1,4 @@
-# Teams and Access Control Architecture
+# Teams and access control architecture

 This document provides an overview of Fleet's Teams and Access Control architecture.

@ -6,22 +6,22 @@ This document provides an overview of Fleet's Teams and Access Control architect

 Teams and Access Control in Fleet enable organizations to manage user access to devices, queries, and other resources based on team membership and roles. This document provides insights into the design decisions, system components, and interactions specific to the Teams and Access Control functionality.

-## Architecture Overview
+## Architecture overview

 The Teams and Access Control architecture enables the organization of devices and users into teams, and the management of user access to resources based on team membership and roles.

-## Key Components
+## Key components

 - **Teams**: Logical groupings of devices and users.
 - **Roles**: Sets of permissions that define what actions users can perform.
 - **Access Control**: The mechanism for controlling user access to resources.
 - **Resource Ownership**: The association of resources with teams.

-## Role-Based Access Control
+## Role-Based Access Control (RBAC)

 Fleet uses role-based access control (RBAC) to manage user access to resources. Roles define what actions users can perform on resources. See our [RBAC guide](https://fleetdm.com/guides/role-based-access) for details.

-## Related Resources
+## Related resources

 - [Role-based access control guide](https://fleetdm.com/guides/role-based-access)
 - [Orchestration Product Group Documentation](../../product-groups/orchestration/) - Documentation for the Orchestration product group
--- a/docs/Contributing/architecture/software/software-automations.md
+++ b/docs/Contributing/architecture/software/software-automations.md
@ -1,4 +1,4 @@
-# Software Policies Architecture
+# Software policies architecture

 This document provides an overview of Fleet's software automation architecture.

@ -6,17 +6,17 @@ This document provides an overview of Fleet's software automation architecture.

 Software automation in Fleet enable organizations automatically install or update software based on a policy.

-## Architecture Overview
+## Architecture overview

-## Key Components
+## Key components

-## Architecture Diagram
+## Architecture diagram

 ```
 [Placeholder for Software Policies Architecture Diagram]
 ```

-## Related Resources
+## Related resources

 - [Software Product Group Documentation](../../product-groups/software/) - Documentation for the Software product group
 - [Software Development Guides](../../guides/software/) - Guides for Software development
--- a/docs/Contributing/architecture/software/software-inventory.md
+++ b/docs/Contributing/architecture/software/software-inventory.md
@ -1,4 +1,4 @@
-# Software Inventory Architecture
+# Software inventory architecture

 This document provides an overview of Fleet's Software Inventory architecture.

--- a/docs/Contributing/architecture/software/software-overview.md
+++ b/docs/Contributing/architecture/software/software-overview.md
@ -1,4 +1,4 @@
-# Software Architecture Overview
+# Software architecture overview

 This document provides an overview of Fleet's Software architecture.

@ -6,7 +6,7 @@ This document provides an overview of Fleet's Software architecture.

 Fleet's Software architecture is designed to manage software across the device fleet, including software inventory, vulnerability management, and software installation. This document provides insights into the design decisions, system components, and interactions specific to the Software functionality.

-## System Components
+## System components

 The Software architecture consists of the following main components:

@ -16,46 +16,46 @@ The Software architecture consists of the following main components:
 - **Software Updates**: The component that manages software updates on devices.
 - **Software Policies**: The component that defines and enforces software policies.

-## Architecture Diagram
+## Architecture diagram

 ```
 [Placeholder for Software Architecture Diagram]
 ```

-## Software Inventory
+## Software inventory

 The Software Inventory component collects and manages information about installed software on devices. It leverages osquery's capabilities to collect software information and Fleet's infrastructure to process and display it.

-### Inventory Collection Flow
+### Inventory collection flow

 1. osquery agent collects software information using osquery tables.
 2. osquery agent sends the information to the Fleet server.
 3. Server processes and stores the information in the database.
 4. UI displays the information to users.

-## Vulnerability Management
+## Vulnerability management

 The Vulnerability Management component identifies and manages software vulnerabilities in the device fleet. It compares installed software versions with known vulnerabilities and provides information about affected devices.

-### Vulnerability Identification Flow
+### Vulnerability identification flow

 1. Server retrieves software inventory information from the database.
 2. Server compares software versions with vulnerability databases.
 3. Server identifies vulnerable software and affected devices.
 4. UI displays vulnerability information to users.

-## Software Installation
+## Software installation

 The Software Installation component manages the installation of software on devices. It leverages platform-specific mechanisms to install software packages.

-### Installation Flow
+### Installation flow

 1. User initiates software installation through the UI or API.
 2. Server sends installation instructions to the device.
 3. Device installs the software using platform-specific mechanisms.
 4. Device reports installation status to the server.

-## Integration Points
+## Integration points

 The Software architecture integrates with the following components:

@ -64,7 +64,7 @@ The Software architecture integrates with the following components:
 - **External Vulnerability Databases**: For retrieving vulnerability information.
 - **Platform-Specific Installation Mechanisms**: For installing software on devices.

-## Related Resources
+## Related resources

 - [Software Product Group Documentation](../../product-groups/software/) - Documentation for the Software product group
 - [Software Development Guides](../../guides/software/) - Guides for Software development
--- a/docs/Contributing/getting-started/README.md
+++ b/docs/Contributing/getting-started/README.md
@ -1,14 +1,14 @@
-# Getting Started with Fleet Development
+# Getting started with Fleet development

 This directory contains documentation to help you get started with Fleet development.

-## Setting Up Your Development Environment
+## Setting up your development environment

 - [Building Fleet](building-fleet.md) - Instructions for building Fleet from source
 - [Testing and Local Development](testing-and-local-development.md) - Guide for testing and local development
 - [Run Locally Built Fleetd](run-locally-built-fleetd.md) - Guide for running a locally built fleetd

-## Next Steps
+## Next steps

 Once you have your development environment set up, you can explore the following resources:

@ -17,7 +17,7 @@ Once you have your development environment set up, you can explore the following
 - [Workflows](../workflows/README.md) - Development workflows
 - [Reference](../reference/README.md) - API reference, configuration, etc.

-## Product Groups
+## Product groups

 Fleet is organized into three main product groups:

--- a/docs/Contributing/getting-started/run-locally-built-fleetd.md
+++ b/docs/Contributing/getting-started/run-locally-built-fleetd.md
@ -2,20 +2,20 @@
 (MacOS)


-### Run fleet server (and the released Fleetd).
+### Run fleet server (and the released Fleetd)
 In order to run a local agent (Fleetd + osquery) the first step is to run the Fleet server locally.
 Follow this document which will run it together with the released agent.
 https://fleetdm.com/docs/contributing/building-fleet

 ### Modify the Fleetd code as needed

-### Build and run locally.
+### Build and run locally
 In order to use a local version we need to create a local TUF service that will point the installer to take the local Fleetd (instead of the official one).
 More details on TUF testing is here:
 https://github.com/fleetdm/fleet/tree/main/tools/tuf/test


-### MacOS - Prepare a script file with this content. Call it my_build.sh:
+### MacOS - Prepare a script file with this content. Call it my_build.sh
 ```sh
 SYSTEMS="macos" \
 PKG_FLEET_URL=https://localhost:8080 \
--- a/docs/Contributing/guides/migrations.md
+++ b/docs/Contributing/guides/migrations.md
@ -4,7 +4,7 @@
 - [Populating the database with default data](#populating-the-database-with-default-data)


-## Adding/Updating tables
+## Adding/updating tables

 We manage database schemas by a series of migrations defined in go code. We use a customized version of the Goose migrations tool to handle these migrations.