diff --git a/specification/README.md b/specification/README.md
index b344673b..fdec03aa 100644
--- a/specification/README.md
+++ b/specification/README.md
@@ -11,11 +11,11 @@ sidebar_position: 0
 
 - [Glossary](./glossary.md)
 - [Types](./types.md)
-- [Evaluation API](./sections/01-flag-evaluation.md)
-- [Providers](./sections//02-providers.md)
-- [Evaluation Context](./sections/03-evaluation-context.md)
-- [Hooks](./sections/04-hooks.md)
-- [Events](./sections/05-events.md)
+- [Evaluation API](./sections/flag-evaluation.md)
+- [Providers](./sections//providers.md)
+- [Evaluation Context](./sections/evaluation-context.md)
+- [Hooks](./sections/hooks.md)
+- [Events](./sections/events.md)
 - [Appendix A: Included Utilities](./appendix-a-included-utilities.md)
 - [Appendix B: Gherkin Suites](./appendix-b-gherkin-suites.md)
 
diff --git a/specification/appendix-b-gherkin-suites.md b/specification/appendix-b-gherkin-suites.md
index 3aeb49ce..98b78efb 100644
--- a/specification/appendix-b-gherkin-suites.md
+++ b/specification/appendix-b-gherkin-suites.md
@@ -13,4 +13,4 @@ These tests can be used to validate the behavior of an OpenFeature implementatio
 
 ## Evaluation Feature
 
-The [evaluation feature](./assets/gherkin/evaluation.feature) contains tests for the basic functionality of the [Evaluation API](./sections/01-flag-evaluation.md).
+The [evaluation feature](./assets/gherkin/evaluation.feature) contains tests for the basic functionality of the [Evaluation API](./sections/flag-evaluation.md).
diff --git a/specification/glossary.md b/specification/glossary.md
index 3b903d39..a5cc9981 100644
--- a/specification/glossary.md
+++ b/specification/glossary.md
@@ -65,7 +65,7 @@ A developer who is setting up or configuring an application or service to use th
 
 ### Provider Author
 
-The maintainer of an API-compliant [provider](./sections/02-providers.md) which implements the necessary interfaces required for flag evaluation.
+The maintainer of an API-compliant [provider](./sections/providers.md) which implements the necessary interfaces required for flag evaluation.
 
 ### Integration Author
 
@@ -105,7 +105,7 @@ A source-of-truth for flag values and rules. Flag management systems may include
 
 ### Provider
 
-An SDK-compliant implementation which resolves flag values from a particular flag management system, allowing the use of the [Evaluation API](./sections/01-flag-evaluation.md#13-flag-evaluation) as an abstraction for the system in question.
+An SDK-compliant implementation which resolves flag values from a particular flag management system, allowing the use of the [Evaluation API](./sections/flag-evaluation.md#13-flag-evaluation) as an abstraction for the system in question.
 
 Providers can be used in two ways. Client-specific providers are active for specific clients, based on their name. The default provider is used if there are no client-specific mappings setup.
 
diff --git a/specification/sections/03-evaluation-context.md b/specification/sections/evaluation-context.md
similarity index 96%
rename from specification/sections/03-evaluation-context.md
rename to specification/sections/evaluation-context.md
index 3bee9503..9c3403b0 100644
--- a/specification/sections/03-evaluation-context.md
+++ b/specification/sections/evaluation-context.md
@@ -12,7 +12,7 @@ toc_max_heading_level: 4
 
 The `evaluation context` provides ambient information for the purposes of flag evaluation. Contextual data may be used as the basis for targeting, including rule-based evaluation, overrides for specific subjects, or fractional flag evaluation.
 
-The context might contain information about the end-user, the application, the host, or any other ambient data that might be useful in flag evaluation. For example, a flag system might define rules that return a specific value based on the user's email address, locale, or the time of day. The context provides this information. The context can be optionally provided at evaluation, and mutated in [before hooks](./04-hooks.md).
+The context might contain information about the end-user, the application, the host, or any other ambient data that might be useful in flag evaluation. For example, a flag system might define rules that return a specific value based on the user's email address, locale, or the time of day. The context provides this information. The context can be optionally provided at evaluation, and mutated in [before hooks](./hooks.md).
 
 ### 3.1 Fields
 
@@ -81,7 +81,7 @@ In the static-context paradigm, context is global. The client and invocation can
 
 > Evaluation context **MUST** be merged in the order: API (global; lowest precedence) -> client -> invocation -> before hooks (highest precedence), with duplicate values being overwritten.
 
-Any fields defined in the client `evaluation context` will overwrite duplicate fields defined globally, and fields defined in the invocation `evaluation context` will overwrite duplicate fields defined globally or on the client. Any resulting `evaluation context` from a [before hook](./04-hooks.md#requirement-434) will overwrite duplicate fields defined globally, on the client, or in the invocation.
+Any fields defined in the client `evaluation context` will overwrite duplicate fields defined globally, and fields defined in the invocation `evaluation context` will overwrite duplicate fields defined globally or on the client. Any resulting `evaluation context` from a [before hook](./hooks.md#requirement-434) will overwrite duplicate fields defined globally, on the client, or in the invocation.
 
 ```mermaid
 flowchart LR
diff --git a/specification/sections/05-events.md b/specification/sections/events.md
similarity index 90%
rename from specification/sections/05-events.md
rename to specification/sections/events.md
index 1db44724..5f3553ad 100644
--- a/specification/sections/05-events.md
+++ b/specification/sections/events.md
@@ -44,7 +44,7 @@ see: [provider event types](./../types.md#provider-events) and [event handlers](
 
 Providers bound to a named client constitute their own "events scope".
 
-see: [setting a provider](./01-flag-evaluation.md#setting-a-provider)
+see: [setting a provider](./flag-evaluation.md#setting-a-provider)
 
 #### Requirement 5.1.4
 
@@ -85,7 +85,7 @@ see: [provider events](#51-provider-events), [`provider event types`](../types.m
 The `provider name` indicates the provider from which the event originated.
 This is especially relevant for global event handlers used for general monitoring, such as alerting on provider errors. 
 
-See [setting a provider](./01-flag-evaluation.md#setting-a-provider), [creating clients](./01-flag-evaluation.md#creating-clients). 
+See [setting a provider](./flag-evaluation.md#setting-a-provider), [creating clients](./flag-evaluation.md#creating-clients). 
 
 #### Requirement 5.2.4
 
@@ -122,7 +122,7 @@ _Application authors_ and _application integrators_ use these events to wait for
 
 > If the provider's `initialize` function terminates normally, `PROVIDER_READY` handlers **MUST** run.
 
-See [provider initialization](./02-providers.md#24-initialization) and [setting a provider](./01-flag-evaluation.md#setting-a-provider).
+See [provider initialization](./providers.md#24-initialization) and [setting a provider](./flag-evaluation.md#setting-a-provider).
 
 #### Requirement 5.3.2
 
@@ -132,7 +132,7 @@ A failed initialization could represent an unrecoverable error, such as bad cred
 If a failed initialization could also represent a transient error.
 A provider which maintains a persistent connection to a remote `flag management system` may attempt to reconnect, and emit `PROVIDER_READY` after a failed initialization.
 
-See [provider initialization](./02-providers.md#24-initialization) and [setting a provider](./01-flag-evaluation.md#setting-a-provider).
+See [provider initialization](./providers.md#24-initialization) and [setting a provider](./flag-evaluation.md#setting-a-provider).
 
 #### Requirement 5.3.3
 
@@ -143,4 +143,4 @@ Handlers should run immediately if the provider is already in the associated sta
 For instance, _application authors_ may attach readiness handlers to be confident that system is ready to evaluate flags.
 If such handlers are attached after the provider underlying the client has already been initialized, they should run immediately.
 
-See [provider initialization](./02-providers.md#24-initialization), [setting a provider](./01-flag-evaluation.md#setting-a-provider).
+See [provider initialization](./providers.md#24-initialization), [setting a provider](./flag-evaluation.md#setting-a-provider).
diff --git a/specification/sections/01-flag-evaluation.md b/specification/sections/flag-evaluation.md
similarity index 94%
rename from specification/sections/01-flag-evaluation.md
rename to specification/sections/flag-evaluation.md
index d04701f6..31290b74 100644
--- a/specification/sections/01-flag-evaluation.md
+++ b/specification/sections/flag-evaluation.md
@@ -10,7 +10,7 @@ toc_max_heading_level: 4
 
 ## Overview
 
-The `evaluation API` allows for the evaluation of feature flag values, independent of any flag control plane or vendor. In the absence of a [provider](./02-providers.md) the `evaluation API` uses the "No-op provider", which simply returns the supplied default flag value.
+The `evaluation API` allows for the evaluation of feature flag values, independent of any flag control plane or vendor. In the absence of a [provider](./providers.md) the `evaluation API` uses the "No-op provider", which simply returns the supplied default flag value.
 
 ### 1.1. API Initialization and Configuration
 
@@ -33,7 +33,7 @@ OpenFeature.setProvider(new MyProvider());
 
 This provider is used if a client is not bound to a specific provider through its name.
 
-See [provider](./02-providers.md), [creating clients](#creating-clients).
+See [provider](./providers.md), [creating clients](#creating-clients).
 
 #### Requirement 1.1.2.2
 
@@ -43,7 +43,7 @@ Application authors can await the newly set `provider's` readiness using the `PR
 Provider instances which are already active (because they have been bound to other `names` or otherwise) need not be initialized again.
 The `provider's` readiness can state can be determined from its `status` member/accessor.
 
-See [event handlers and initialization](./05-events.md#event-handlers-and-initialization), [provider initialization](./02-providers.md#24-initialization).
+See [event handlers and initialization](./events.md#event-handlers-and-initialization), [provider initialization](./providers.md#24-initialization).
 
 #### Requirement 1.1.2.3
 
@@ -52,7 +52,7 @@ See [event handlers and initialization](./05-events.md#event-handlers-and-initia
 When a provider is no longer in use, it should be disposed of using its `shutdown` mechanism.
 Provider instances which are bound to multiple names won't be shut down until the last binding is removed.
 
-see: [shutdown](./02-providers.md#25-shutdown), [setting a provider](#setting-a-provider)
+see: [shutdown](./providers.md#25-shutdown), [setting a provider](#setting-a-provider)
 
 #### Requirement 1.1.3
 
@@ -75,7 +75,7 @@ See [creating clients](#creating-clients).
 OpenFeature.addHooks([new MyHook()]);
 ```
 
-See [hooks](./04-hooks.md) for details.
+See [hooks](./hooks.md) for details.
 
 #### Requirement 1.1.5
 
@@ -86,7 +86,7 @@ See [hooks](./04-hooks.md) for details.
 OpenFeature.getProviderMetadata();
 ```
 
-See [provider](./02-providers.md) for details.
+See [provider](./providers.md) for details.
 
 ### Creating clients
 
@@ -128,7 +128,7 @@ OpenFeatureAPI.getInstance().setProviderAndWait('client-name', myprovider); // t
 Client client = OpenFeatureAPI.getInstance().getClient('client-name');
 ```
 
-Though it's possible to use [events](./05-events.md) to await provider readiness, such functions can make things simpler for `application authors` and `integrators`.
+Though it's possible to use [events](./events.md) to await provider readiness, such functions can make things simpler for `application authors` and `integrators`.
 
 ### 1.2. Client Usage
 
@@ -141,7 +141,7 @@ Though it's possible to use [events](./05-events.md) to await provider readiness
 client.addHooks([new MyHook()]);
 ```
 
-See [hooks](./04-hooks.md) for details.
+See [hooks](./hooks.md) for details.
 
 #### Requirement 1.2.2
 
@@ -179,7 +179,7 @@ number myNumber = client.getNumberValue('number-flag', 75);
 MyStruct myStruct = client.getObjectValue<MyStruct>('structured-flag', { text: 'N/A', percentage: 75 }, evaluationContext, options);
 ```
 
-See [evaluation context](./03-evaluation-context.md) for details.
+See [evaluation context](./evaluation-context.md) for details.
 
 #### Condition 1.3.2
 
@@ -367,7 +367,7 @@ This `flag metadata` field is intended as a mechanism for providers to surface a
 
 > The `evaluation options` structure's `hooks` field denotes an ordered collection of hooks that the client **MUST** execute for the respective flag evaluation, in addition to those already configured.
 
-See [hooks](./04-hooks.md) for details.
+See [hooks](./hooks.md) for details.
 
 ### 1.6. Shutdown
 
@@ -380,4 +380,4 @@ See [hooks](./04-hooks.md) for details.
 The global API object might expose a `shutdown` function, which will call the respective `shutdown` function on the registered providers.
 Alternatively, implementations might leverage language idioms such as auto-disposable interfaces or some means of cancellation signal propagation to allow for graceful shutdown.
 
-see: [`shutdown`](./02-providers.md#25-shutdown)
+see: [`shutdown`](./providers.md#25-shutdown)
diff --git a/specification/sections/04-hooks.md b/specification/sections/hooks.md
similarity index 96%
rename from specification/sections/04-hooks.md
rename to specification/sections/hooks.md
index 2f7ebe78..87c2c9a3 100644
--- a/specification/sections/04-hooks.md
+++ b/specification/sections/hooks.md
@@ -19,7 +19,7 @@ Hooks add their logic at any of four specific stages of flag evaluation:
 
 ![Flag evaluation life cycle](../assets/images/life-cycle.png)
 
-Hooks can be configured to run globally (impacting all flag evaluations), per client, or per flag evaluation invocation. Some example use-cases for hook include adding additional data to the [evaluation context](./03-evaluation-context.md), performing validation on the received flag value, providing data to telemetric tools, and logging errors.
+Hooks can be configured to run globally (impacting all flag evaluations), per client, or per flag evaluation invocation. Some example use-cases for hook include adding additional data to the [evaluation context](./evaluation-context.md), performing validation on the received flag value, providing data to telemetric tools, and logging errors.
 
 ### Definitions
 
@@ -111,7 +111,7 @@ void before(HookContext hookContext, HookHints hints);
 
 > When `before` hooks have finished executing, any resulting `evaluation context` **MUST** be merged with the existing `evaluation context`.
 
-Evaluation context merge order is defined in [Context levels and merging](./03-evaluation-context.md#32-context-levels-and-merging).
+Evaluation context merge order is defined in [Context levels and merging](./evaluation-context.md#32-context-levels-and-merging).
 
 #### Requirement 4.3.6
 
@@ -198,7 +198,7 @@ val = client.get_boolean_value('my-key', False, evaluation_options={
 })
 ```
 
-see: [Flag evaluation options](./01-flag-evaluation.md#)
+see: [Flag evaluation options](./flag-evaluation.md)
 
 #### Requirement 4.5.1
 
diff --git a/specification/sections/02-providers.md b/specification/sections/providers.md
similarity index 94%
rename from specification/sections/02-providers.md
rename to specification/sections/providers.md
index f0497bff..555b9734 100644
--- a/specification/sections/02-providers.md
+++ b/specification/sections/providers.md
@@ -12,7 +12,7 @@ toc_max_heading_level: 4
 
 The `provider` API defines interfaces that Provider Authors can use to abstract a particular flag management system, thus enabling the use of the `evaluation API` by Application Authors.
 
-Providers are the "translator" between the flag evaluation calls made in application code, and the flag management system that stores flags and in some cases evaluates flags. At a minimum, providers should implement some basic evaluation methods which return flag values of the expected type. In addition, providers may transform the [evaluation context](./03-evaluation-context.md) appropriately in order to be used in dynamic evaluation of their associated flag management system, provide insight into why evaluation proceeded the way it did, and expose configuration options for their associated flag management system. Hypothetical provider implementations might wrap a vendor SDK, embed an REST client, or read flags from a local file.
+Providers are the "translator" between the flag evaluation calls made in application code, and the flag management system that stores flags and in some cases evaluates flags. At a minimum, providers should implement some basic evaluation methods which return flag values of the expected type. In addition, providers may transform the [evaluation context](./evaluation-context.md) appropriately in order to be used in dynamic evaluation of their associated flag management system, provide insight into why evaluation proceeded the way it did, and expose configuration options for their associated flag management system. Hypothetical provider implementations might wrap a vendor SDK, embed an REST client, or read flags from a local file.
 
 ![Provider](../assets/images/provider.png)
 
@@ -129,7 +129,7 @@ ResolutionDetails<MyStruct> resolveStructureValue(string flagKey, MyStruct defau
 
 ### 2.3. Provider hooks
 
-A `provider hook` exposes a mechanism for `provider authors` to register [`hooks`](./04-hooks.md) to tap into various stages of the flag evaluation lifecycle. These hooks can be used to perform side effects and mutate the context for purposes of the provider. Provider hooks are not configured or controlled by the `application author`.
+A `provider hook` exposes a mechanism for `provider authors` to register [`hooks`](./hooks.md) to tap into various stages of the flag evaluation lifecycle. These hooks can be used to perform side effects and mutate the context for purposes of the provider. Provider hooks are not configured or controlled by the `application author`.
 
 #### Requirement 2.3.1
 
diff --git a/specification/types.md b/specification/types.md
index 13880c9e..751c2084 100644
--- a/specification/types.md
+++ b/specification/types.md
@@ -32,7 +32,7 @@ A language primitive for representing a date and time, optionally including time
 
 ### Evaluation Details
 
-A structure representing the result of the [flag evaluation process](./glossary.md#evaluating-flag-values), and made available in the [detailed flag resolution functions](./sections/01-flag-evaluation.md#14-detailed-flag-evaluation), containing the following fields:
+A structure representing the result of the [flag evaluation process](./glossary.md#evaluating-flag-values), and made available in the [detailed flag resolution functions](./sections/flag-evaluation.md#14-detailed-flag-evaluation), containing the following fields:
 
 - flag key (string, required)
 - value (boolean | string | number | structure, required)
@@ -94,13 +94,13 @@ An enumerated error code represented idiomatically in the implementation languag
 
 A structure containing the following fields:
 
-- hooks (one or more [hooks](./sections/04-hooks.md), optional)
+- hooks (one or more [hooks](./sections/hooks.md), optional)
 
 ### Flag Metadata
 
 A structure which supports definition of arbitrary properties, with keys of type `string`, and values of type `boolean`, `string`, or `number`.
 
-This structure is populated by a provider for use by an [Application Author](./glossary.md#application-author) (via the [Evaluation API](./glossary.md#evaluation-api)) or an [Application Integrator](./glossary.md#application-integrator) (via [hooks](./sections/04-hooks.md)).
+This structure is populated by a provider for use by an [Application Author](./glossary.md#application-author) (via the [Evaluation API](./glossary.md#evaluation-api)) or an [Application Integrator](./glossary.md#application-integrator) (via [hooks](./sections/hooks.md)).
 
 ### Provider Status