diff --git a/src/_guides/openapi/specification/v3.1/advanced/splitting-documents-with-ref.md b/src/_guides/openapi/specification/v3.1/advanced/splitting-documents-with-ref.md
index dfef315e..f7a3c6be 100644
--- a/src/_guides/openapi/specification/v3.1/advanced/splitting-documents-with-ref.md
+++ b/src/_guides/openapi/specification/v3.1/advanced/splitting-documents-with-ref.md
@@ -253,7 +253,7 @@ Is that a good thing or a bad thing? It can be both depending on the scenario, b
 
 ## Tools for Bundling & Splitting 
 
-Bundling is usually only needed if you are working with older or strange tools which do not support $ref properly (or at all). If you are working with Bump.sh CLI you won’t need to bundle, but if a tool wants you to import a single `openapi.yaml` document you might need to bundle.
+Bundling is usually only needed if you are working with older or strange tools which do not support `$ref` properly (or at all). If you are working with Bump.sh CLI you won’t need to bundle, but if a tool wants you to import a single `openapi.yaml` document you might need to bundle.
 
 ```
 $ redocly bundle openapi.yaml -o openapi-bundled.yaml
@@ -264,6 +264,7 @@ bundling openapi.yaml...
 This will grab all of the `$ref`'s that use "external files" or URLs and move the contents into the relevant subsection of `components` in the `openapi-bundled.yaml` document.
 
 Splitting does the opposite. If you have a massive painful document (maybe generated from HTTP or converted from Postman) you can split it down into multiple documents with a sensible folder structure, ditch the original, commit all that to Git, and push it up to Bump.sh with all the `$ref`'s intact.
+
 ```
 redocly split generated-openapi.json --outDir api/
 
diff --git a/src/_guides/openapi/specification/v3.1/data-models/schema-and-data-types.md b/src/_guides/openapi/specification/v3.1/data-models/schema-and-data-types.md
index 7885a719..44898db9 100644
--- a/src/_guides/openapi/specification/v3.1/data-models/schema-and-data-types.md
+++ b/src/_guides/openapi/specification/v3.1/data-models/schema-and-data-types.md
@@ -21,7 +21,9 @@ The first thing to learn about a schema is the `type` keyword, which can be one
 - array
 - number
 - string
-- integer (matches any number with a zero fractional part)
+
+> You can also use "integer" for the sake of convenience, but "integer" and "number" are basically identical because JSON itself does not make that distinction. Since there is no distinct JSON integer type, JSON Schema defines integers mathematically. This means that both 1 and 1.0 are equivalent, and are both considered to be integers.
+{: .info }
 
 A schema object looks like this:
 
@@ -147,7 +149,7 @@ You can also define your own custom formats, which tooling will not understand,
 
 In addition to defining data types and formats, [JSON Schema](_guides/openapi/specification/v3.1/data-models/json-schema.md) provides several validation keywords to enforce specific constraints on the data. Here are a few popular validation keywords:
 
-## const & enum
+### const & enum
 
 Restricting a value down to one or more potential values can be done with the `const` or `enum` keywords. 
 
@@ -212,7 +214,7 @@ In this example the `object` could be `card` or `bank_account`, but instead of d
 {: .info }
 
 
-## default 
+### default 
 
 Setting a `default` lets people and code know what to do when a value has not been provided. 
 
@@ -227,7 +229,7 @@ enum:
 
 
 
-### minimum and maximum
+### minimum & maximum
 
 The `minimum` and `maximum` keywords allow you to specify the minimum and maximum values for numeric properties. For example:
 
@@ -280,6 +282,6 @@ This schema mandates that the properties "name" and "age" must be present in the
 For more information on JSON Schema validation keywords, you can refer to the [JSON Schema Validation documentation](https://json-schema.org/learn/validation.html).
 
 
-### Learn more about JSON Schema
+## Learn more about JSON Schema
 
 There is a lot more to JSON Schema and OpenAPI Schema Objects than we've covered here, but this will hopefully get you off to a good start. If you need to learn more, you can read our guide on [JSON Schema in OpenAPI](_guides/openapi/specification/v3.1/data-models/json-schema.md).
diff --git a/src/_help/specification-support/json-schema.md b/src/_help/specification-support/json-schema.md
index b1498a73..881bf03f 100644
--- a/src/_help/specification-support/json-schema.md
+++ b/src/_help/specification-support/json-schema.md
@@ -57,7 +57,7 @@ Thus, it becomes easy to use the same `Schema Object` in different contexts, for
 > - `readOnly` properties **are hidden** when they belong to a `publish` operation in AsyncAPI or a `request` in OpenAPI.
 {: .warning}
 
-> Not displaying `writeOnly` properties in subscribe operations and `readOnly` properties in publish operations allows the use of the same `Schema Object` everywhere it is needed, without generating  confusing informations in the documentation.
+> Not displaying `writeOnly` properties in subscribe operations and `readOnly` properties in publish operations allows the use of the same `Schema Object` everywhere it is needed, without documenting confusing/irrelevant properties in the wrong context.
 {: .info}