diff --git a/semantic_conventions/README.md b/semantic_conventions/README.md
index 40400c0d68c..64e4e821945 100644
--- a/semantic_conventions/README.md
+++ b/semantic_conventions/README.md
@@ -17,12 +17,12 @@ i.e.:
 Semantic conventions for the spec MUST adhere to the
 [attribute naming conventions](../specification/common/attribute-naming.md).
 
-Refer to the [syntax](https://github.com/open-telemetry/build-tools/tree/v0.6.0/semantic-conventions/syntax.md)
+Refer to the [syntax](https://github.com/open-telemetry/build-tools/tree/v0.7.0/semantic-conventions/syntax.md)
 for how to write the YAML files for semantic conventions and what the YAML properties mean.
 
 A schema file for VS code is configured in the `/.vscode/settings.json` of this
 repository, enabling auto-completion and additional checks. Refer to
-[the generator README](https://github.com/open-telemetry/build-tools/tree/v0.6.0/semantic-conventions/README.md) for what extension you need.
+[the generator README](https://github.com/open-telemetry/build-tools/tree/v0.7.0/semantic-conventions/README.md) for what extension you need.
 
 ## Generating markdown
 
@@ -33,7 +33,7 @@ formatted Markdown tables for all semantic conventions in the specification. Run
 make table-generation
 ```
 
-For more information, see the [semantic convention generator](https://github.com/open-telemetry/build-tools/tree/v0.6.0/semantic-conventions)
+For more information, see the [semantic convention generator](https://github.com/open-telemetry/build-tools/tree/v0.7.0/semantic-conventions)
 in the OpenTelemetry build tools repository.
 Using this build tool, it is also possible to generate code for use in OpenTelemetry
 language projects.
diff --git a/specification/trace/semantic_conventions/exceptions.md b/specification/trace/semantic_conventions/exceptions.md
index b6ada64aa3c..b54552a1713 100644
--- a/specification/trace/semantic_conventions/exceptions.md
+++ b/specification/trace/semantic_conventions/exceptions.md
@@ -7,16 +7,16 @@ exceptions.
 
 <!-- toc -->
 
-- [Recording an Exception](#recording-an-exception)
-- [Attributes](#attributes)
-  - [Stacktrace Representation](#stacktrace-representation)
+- [Semantic Conventions for Exceptions](#semantic-conventions-for-exceptions)
+  - [Recording an Exception](#recording-an-exception)
+  - [Semantic definitions and attributes](#semantic-definitions-and-attributes)
+    - [Stacktrace Representation](#stacktrace-representation)
 
 <!-- tocstop -->
 
 ## Recording an Exception
 
 An exception SHOULD be recorded as an `Event` on the span during which it occurred.
-The name of the event MUST be `"exception"`.
 
 <a name="exception-end-example"></a>
 
@@ -36,12 +36,11 @@ try {
 }
 ```
 
-## Attributes
-
-The table below indicates which attributes should be added to the `Event` and
-their types.
+## Semantic definitions and attributes
 
 <!-- semconv exception -->
+The event name MUST be `exception`.
+
 | Attribute  | Type | Description  | Examples  | Required |
 |---|---|---|---|---|
 | `exception.type` | string | The type of the exception (its fully-qualified class name, if applicable). The dynamic type of the exception should be preferred over the static type in languages that support it. | `java.net.ConnectException`; `OSError` | See below |
diff --git a/specification/trace/semantic_conventions/rpc.md b/specification/trace/semantic_conventions/rpc.md
index 87879313a6b..1988966a17c 100644
--- a/specification/trace/semantic_conventions/rpc.md
+++ b/specification/trace/semantic_conventions/rpc.md
@@ -150,9 +150,9 @@ client and server spans SHOULD be created. In case of
 unary calls only one sent and one received message will be recorded for both
 client and server spans.
 
-The event name MUST be `"message"`.
-
 <!-- semconv rpc.grpc.message -->
+The event name MUST be `message`.
+
 | Attribute  | Type | Description  | Examples  | Required |
 |---|---|---|---|---|
 | `message.type` | string | Whether this is a received or sent message. | `SENT` | No |