diff --git a/.gitmodules b/.gitmodules
new file mode 100644
index 0000000..0c48a09
--- /dev/null
+++ b/.gitmodules
@@ -0,0 +1,3 @@
+[submodule "akm/documentation/themes/learn"]
+ path = akm/documentation/themes/learn
+ url = https://github.com/matcornic/hugo-theme-learn.git
diff --git a/akm/documentation/README.md b/akm/documentation/README.md
new file mode 100755
index 0000000..3dc623f
--- /dev/null
+++ b/akm/documentation/README.md
@@ -0,0 +1,62 @@
+# AKM Documentation
+
+The AKM documentation is realized with GitHub Pages. It is generated from
+the markdown files in the ```/documentation``` directory of this repository.
+The static webpage is generated automatically after every PR merged to master
+and deployed into a branch called `gh-pages`.
+
+
+### Dependencies
+
+The static page is generated with:
+
+- [HUGO](https://gohugo.io/)
+- [Learn Theme](https://themes.gohugo.io/hugo-theme-learn/)
+
+Please follow the [documentation](https://gohugo.io/documentation/) for installation and further questions around the framework.
+
+### Run the documentation server locally
+
+Once hugo is installed please follow the following steps:
+
+#### Check that HUGO is working:
+```
+hugo version
+```
+The following outcome is expected:
+
+```
+Hugo Static Site Generator v0.xx.xx ...
+```
+
+#### Clone the submodule containing the theme
+
+Run the following git commands to init and fetch the submodules:
+
+```
+git submodule init
+git submodule update
+```
+
+Reference: [Git Documentation](https://git-scm.com/book/en/v2/Git-Tools-Submodules).
+
+#### Test locally on your server:
+
+Within the repository
+
+```
+hugo server -D -s akm/documentation
+```
+
+Optional ```-D:``` include draft pages as well. Afterwards, you can access the
+page under http://localhost:1313/Automotive_Knowledge_Model/
+
+### Contribute
+
+If you want to contribute, do the following:
+
+1. **Change documentation in ```/documentation```**
+
+1. **Test your changes locally, as described above**
+
+1. **Create Pull Request for review**
diff --git a/akm/documentation/config.toml b/akm/documentation/config.toml
new file mode 100755
index 0000000..84616da
--- /dev/null
+++ b/akm/documentation/config.toml
@@ -0,0 +1,27 @@
+baseURL = "https://localhost/Automotive_Knowledge_Model/"
+languageCode = "en-us"
+title = "Automotive Knowledge Model"
+theme = "learn"
+publishDir = "../docs"
+[params]
+ # Change default color scheme with a variant one. Can be "red", "blue", "green".
+ themeVariant = "blue"
+ disableInlineCopyToClipBoard = true
+ editURL = "https://localhost/automotive_knowledge_model/edit/master/docs-gen/content/"
+ disableLandingPageButton = true
+
+
+[[menu.shortcuts]]
+name = " Github repo"
+identifier = "ds"
+url = "https://github.com/COVESA/akm"
+weight = 10
+
+[[menu.shortcuts]]
+name = " Releases"
+url = "https://github.com/COVESA/akm/releases"
+weight = 12
+
+# Generation of JSON index to allow search
+[outputs]
+home = [ "HTML", "RSS", "JSON"]
diff --git a/akm/documentation/content/_index.md b/akm/documentation/content/_index.md
new file mode 100755
index 0000000..6dd704d
--- /dev/null
+++ b/akm/documentation/content/_index.md
@@ -0,0 +1,13 @@
+---
+title: "Automotive Knowledge Model"
+---
+
+# Automotive Knowledge Model (AKM)
+This repo contains the Automotive Knowledge Model (AKM), an expressive and extensible semantics and
+standards-based vocabulary and data model for automobiles.
+
+The source code and releases can be found in here [AKM github repository](https://github.com/COVESA/akm).
+
+
+
+
diff --git a/akm/documentation/content/ecosystem/_index.md b/akm/documentation/content/ecosystem/_index.md
new file mode 100755
index 0000000..bbcdbdc
--- /dev/null
+++ b/akm/documentation/content/ecosystem/_index.md
@@ -0,0 +1,6 @@
+---
+title: "Ecosystem"
+chapter: true
+weight: 60
+---
+
diff --git a/akm/documentation/content/ecosystem/tools.md b/akm/documentation/content/ecosystem/tools.md
new file mode 100755
index 0000000..8c059d8
--- /dev/null
+++ b/akm/documentation/content/ecosystem/tools.md
@@ -0,0 +1,11 @@
+---
+title: "Tools"
+weight: 1
+---
+
+The AKM can be transformed into other formats or integrate with other tooling environments and ecosystems.
+
+AKM-tools provide tooling to generate data model artifacts in different formats.
+
+
+The source code for akm-tools can be found here [akm-tools](https://github.com/COVESA/akm/tree/main/akm_tools).
diff --git a/akm/documentation/content/extensions/_index.md b/akm/documentation/content/extensions/_index.md
new file mode 100755
index 0000000..9692c41
--- /dev/null
+++ b/akm/documentation/content/extensions/_index.md
@@ -0,0 +1,57 @@
+
+---
+title: Extensions
+weight: 50
+chapter: true
+---
+
+# Extensions
+Extensions enable organizations to append new schema elements and data to the AKM. Schema extensions are added to the akm/extensions/schema folder and data extensions are added to the akm/extensions/data folder.
+
+The AKM adheres to the Open/Closed principle and does not provide a mechanism for overriding or redefining entries in the public AKM, which would invalidate the nature of a shared vocabulary.
+
+
+## Example
+The following example demonstrates how the Data Type is extended to include the corresponding json and xsd data types.
+#### akm/extensions/schema/data_type.json
+ ```JSON
+{
+ "$id": "akm.extension.DataType",
+ "type": "object",
+ "description": "Extended properties for DataType",
+ "properties": {
+ "jsonDataType": {
+ "type": "string",
+ "description": "The JSON data type as that correlates to this data type"
+ },
+ "xsdDataType": {
+ "type": "string",
+ "description": "The XML Schema data type as that correlates to this data type"
+ }
+ },
+ "required": []
+}
+```
+#### akm/extensions/data_types.json
+ ```JSON
+{
+ "id": "boolean",
+ "name": "boolean",
+ "definition": "A binary data type that represents two possible values- true or false",
+ "entityTypeID": "DataType",
+ "jsonDataType": "boolean",
+ "xsdDataType": "xsd:boolean"
+}
+```
+ ```JSON
+{
+ "id": "int16",
+ "name": "int16",
+ "definition": "16-bit signed integer for range -32768 to 32767",
+ "entityTypeID": "DataType",
+ "jsonDataType": "json:integer",
+ "xsdDataType": "xsd:short",
+ "min": -32768,
+ "max": 32767
+}
+```
\ No newline at end of file
diff --git a/akm/documentation/content/governance/_index.md b/akm/documentation/content/governance/_index.md
new file mode 100755
index 0000000..05d2123
--- /dev/null
+++ b/akm/documentation/content/governance/_index.md
@@ -0,0 +1,7 @@
+---
+title: Governance
+weight: 100
+chapter: false
+---
+
+ TBD
diff --git a/akm/documentation/content/license/_index.md b/akm/documentation/content/license/_index.md
new file mode 100755
index 0000000..c679326
--- /dev/null
+++ b/akm/documentation/content/license/_index.md
@@ -0,0 +1,7 @@
+---
+title: License
+weight: 70
+chapter: false
+---
+
+ TBD
diff --git a/akm/documentation/content/overview/_index.md b/akm/documentation/content/overview/_index.md
new file mode 100755
index 0000000..4ae1f8d
--- /dev/null
+++ b/akm/documentation/content/overview/_index.md
@@ -0,0 +1,24 @@
+
+---
+title: Overview
+weight: 10
+chapter: true
+---
+
+# Overview
+The Automotive Knowledge Model (AKM) is an expressive and extensible semantics and standards-based vocabulary and data model for automobiles. It is defined in two major sections:
+## Schema
+The schema describes the AKM data model. The schema is represented in [JSON Schema](https://json-schema.org/) which provides many benefits:
+
+ - The standard is well-known, documented, and easy to read
+ - It has a large ecosystem of [tools and implementations](https://json-schema.org/implementations) such as validators, code generators, and format converters.
+ - It provides built-in support for creating an expressive schema with such things as objects, properties, references, arrays, enumerations, extensions, and regular expressions.
+ - It is self-documenting
+
+ ### Diagram
+ The diagram below captures most of the classes and their relationships.
+
+
+
+## Data
+The data includes json files that contain reference data such as standard data types and units, as well as common and generally useful master data such as metrics, features of interest, and properties.
diff --git a/akm/documentation/content/overview/images/Model.PNG b/akm/documentation/content/overview/images/Model.PNG
new file mode 100755
index 0000000..365ca1c
Binary files /dev/null and b/akm/documentation/content/overview/images/Model.PNG differ
diff --git a/akm/documentation/content/principles/_index.md b/akm/documentation/content/principles/_index.md
new file mode 100755
index 0000000..6312e33
--- /dev/null
+++ b/akm/documentation/content/principles/_index.md
@@ -0,0 +1,67 @@
+
+---
+title: "Principles"
+chapter: true
+weight: 20
+---
+
+# Principles
+
+This page covers some of the principles that guided the creation of the AKM and that should be followed when contributing to it.
+
+
+## Data-Centric
+A layered design that separates data from algorithms increases opportunities for extension, reuse, and independent development. The AKM is intended to represent the things that exist in the vehicle information domain with no bias toward any particular use by vehicle or software components. The following practices support this principle:
+- Every entry within the AKM has an explicit unique identifier so it can be directly accessed
+- References from one entry to another are explicitly expressed rather than encoded within a field or implied by other means such as its position in a file or folder.
+- The AKM makes no assumptions about query patterns and is expressive enough to derive graphs, tables, trees, various types of files, and other derived structures deemed useful.
+
+## Connected
+Vehicle information is highly connected, so the AKM allows objects to refer to related objects. Examples include:
+- Part-to-Whole relationships using the ***partOf*** property
+ - The driver's seatbelt can refer to the driver's seat that contains it.
+ - The radio can indicate that it is part of the infotainment system.
+- Generalization inheritance using the ***isA*** property
+ - The front passenger HVAC station can indicate that it is a HVAC station.
+ - The rear driver-side door can indicate that it is a cabin door.
+- Peer-to-peer associations
+ - The VehicleTravel.Speed metric can indicate that its feature of interest is VehicleTravel, and that its property is Speed.
+ - The Speed property can indicate that its default unit of measurement is kilometer per hour, and that its data type is float.
+
+## Atomic
+An atomic concept is the smallest unit of meaning that can be modeled. Separating concepts into their atomic components allows for more flexibility, accuracy, and efficiency in storing and querying data. The AKM maintains separate objects for metrics, features of interest, data and object properties, units of measurement, and data types. It includes embedded objects for deprecation facts and mappings to other schemas. Separating objects and properties by their atomic meanings provides several advantages.
+
+- Reduce errors in software and database development by ensuring that data is consistent and valid.
+- Increase consistency in documentation and system design by using common terms, patterns, and standards.
+- Improve application and database performance by minimizing data redundancy and optimizing data structures.
+- Ease data mapping and improve communication between data providers and consumers.
+
+## Extensible
+Extensibility is the ability to add capabilities without rewriting code or changing the basic architecture. Extensibility allows users and their software systems to quickly adapt to dynamic market and technology conditions. The AKM is designed so that users can extend the schema with new classes, objects, properties, and attributes without breaking existing code. Generally useful extensions can be submitted to the repository for review and acceptance.
+
+Some ways that AKM provides extensibility are:
+- The model eschews enumerations in favor of explicit objects. Instead of an enumeration of data types, for instance, the model defines a DataType class whose members are stored as json objects.
+- The model discourages the use of discrete identifiers (sometimes called "magic numbers"). For instance, rather than encode metric information in a field value as *Vehicle.Speed.KilometerPerHour.UInt8*, the metric explicitly articulates that information as *featureOfinterest: VehicleTravel, property: Speed, Unit: kilometer_per_hour*, and *dataType: uint8*.
+- Custom extensions are ignored by any validation or tools provided in the public repository.
+- The information is expressive and articulate enough to support the inference and automation enabled by formal knowledge systems like ontologies.
+
+## Standardized
+Standards allow information to flow seamlessly between systems and organizations. AKM is designed to promote internal consistency by providing a well-defined set of objects that represent vehicle metrics.
+### Internal Standards
+AKM employs standards to ensure its quality and consistency.
+
+- Objects inherit from a standard ***Entity*** that defines common properties such as name, definition, comment, etc.
+- All objects and properties fields include their definition using the JSON Schema ***description*** keyword.
+### External Standards
+AKM is also designed to utilize external standards.
+#### Standard Schema Language
+[JSON Schema](https://json-schema.org/) is a well-known vocabulary that enables JSON data consistency, validity, and interoperability at scale.
+#### Common Terms and Vocabularies
+AKM tries to appropriate established terms where possible, and its main classes provide an example:
+- **Feature of Interest** is a common term in IoT vocabularies, including:
+ >- [SOSA](https://www.w3.org/TR/vocab-ssn/) - the Sensor, Observation, Sample, and Actuator Ontology
+ >- [SAREF](https://saref.etsi.org/core/v3.1.1/) - the Smart Applications REFerence ontology
+ >- The [OGC SensorThings API](https://www.ogc.org/standard/sensorthings/)
+ >
+- **Property** is a term used in many programming languages to indicate an attribute that can be observed (read) or manipulated (written).
+- **Metric** is a common business intelligence term to indicate something that is measured but doesn't include the measurements themselves.
diff --git a/akm/documentation/content/schema/_index.md b/akm/documentation/content/schema/_index.md
new file mode 100755
index 0000000..01ffc4d
--- /dev/null
+++ b/akm/documentation/content/schema/_index.md
@@ -0,0 +1,17 @@
+---
+title: Schema
+weight: 30
+chapter: true
+---
+
+# JSON Schema Files
+AKM uses JSON schema files files that express the format of AKM data objects.
+([JSON Schema](https://json-schema.org/))
+
+ It is the intent that this schema can be used to:
+
+- Document the types and structure of AKM objects and properties
+- Validate the structures and values in AKM data objects
+- Leverage widely-available JSON and JSON Schema tooling
+
+At this stage, all document types and properties are contained in a single file: automotive_knowledge_model.json
diff --git a/akm/documentation/content/schema/entity_types.md b/akm/documentation/content/schema/entity_types.md
new file mode 100755
index 0000000..a525371
--- /dev/null
+++ b/akm/documentation/content/schema/entity_types.md
@@ -0,0 +1,148 @@
+
+
+
+---
+title: "Entity Types"
+weight: 1
+---
+
+### Main Entity Types
+There are three main entity types:
+- A ***Feature of Interest*** is a thing whose state or condition can be observed or manipulated.
+ Examples include the vehicle, driver, steering wheel, and tailgate.
+
+- A ***Property*** is an attribute or characteristic that can describe one or more features of interest. Examples include speed, compass direction, temperature, and whether a switch is set to on or off.
+
+- A ***Metric*** is a type of signal that specifies a particular property of a particular feature of interest. Examples include the vehicle identification number, the direction that the vehicle is heading, the ambient temperature in the cabin, and whether the driver door is locked.
+
+>**Note:** The catalog does **not** include the actual measurements with the values of the metrics, such as:
+>- The vehicle is traveling at ***84** kilometers per hour*.
+>- The transmission is currently in ***third** gear*.
+>- The driver's door is ***unlocked***.
+>- The vehicle identification number is "***1FT7X2BT5CEC66117***".
+
+**Note**: AKM provides for representations of other signal schemas such as the [Vehicle Signal Specification](https://covesa.github.io/vehicle_signal_specification/introduction/overview/) (VSS) or CAN Bus, as well as conversions between their values. Thus, it can both generate and understand signals from these schemas.
+
+### Supporting Entity Types
+
+#### General Supporting Entity Types
+- An ***Entity*** is an abstract superclass that other entity types inherit from. It provides the requirement that every object will have an identifier, name, and definition. It also defines other common properties such as comment and deprecation.
+
+- An ***EntityType*** is a metatype that classifies other types of objects. As described in this document, there are entity types for *Feature of Interest*, *Property*, *Data Type*, etc. The data model can be extended by adding new entity types.
+
+- A ***Representation*** describes an equivalent signal as it exists in another schema. The *Metric* entity type can include an array of *Representations*.
+
+- A ***Deprecation*** object can be embedded into metadata entries to document entries that are no longer maintained and/or supported.
+
+#### Data Property Supporting Entity Types
+
+- A ***Data Type*** is a classification of data elements that prescribes which values they can take, their size, and what type of mathematical, relational, or logical operations can be applied to them. Examples include boolean, string, and numeric types such as int32, uint16, double, and float.
+
+- A ***Unit*** is a standard within a governed system by which a quantity can be expressed and universally understood. Examples include units of measurement such as kilometer, liter, and degree Celsius; as well as units of concentration such as percent and parts per million.
+
+## Vehicle Metrics Metadata
+The AKM includes instances of many objects commonly used in the vehicle signal domain. Because these objects share the standardized structure and meaning declared in the data model, they can be shared between organizations with no loss of meaning.
+
+### Examples
+
+#### Driver Seatbelt (Feature of Interest)
+ ```JSON
+{
+ "id": "Seatbelt.Row1.DriverSide",
+ "name": "Seatbelt at Row 1 Driver Side",
+ "definition": "Seatbelt at Row 1 Driver Side",
+ "entityTypeID": "FeatureOfInterest",
+ "partOf": {
+ "entityTypeID": "FeatureOfInterest",
+ "id": "Seat.Row1.DriverSide"
+ },
+ "isA": {
+ "entityTypeID": "FeatureOfInterestClass",
+ "id": "Seatbelt"
+ }
+}
+```
+
+#### Is Fastened (Boolean Data Property)
+ ```JSON
+{
+ "id": "IsFastened",
+ "name": "Is Fastened",
+ "definition": "A boolean variable indicating that the subject has affixed its mating mechanical parts to securely connect its corresponding components",
+ "entityTypeID": "DataProperty",
+ "dataType": {
+ "entityTypeID": "DataType",
+ " id": "boolean"
+ }
+}
+```
+#### Driver Seatbelt is Fastened (Metric)
+ ```JSON
+{
+ "id": "Seatbelt.Row1.DriverSide.IsFastened",
+ "name": "Seatbelt at Row1 Driver Side Is Fastened",
+ "definition": "A boolean variable indicating whether the Front Driver Seatbelt Is Fastened",
+ "entityTypeID": "Metric",
+ "featureOfInterest": {
+ "referentEntityTypeID": "FeatureOfInterest",
+ "referentID": "Seatbelt.Row1.DriverSide"
+ },
+ "property": {
+ "referentEntityTypeID": "Property",
+ "referentID": "IsFastened"
+ }
+}
+
+```
+#### Latitude (Numeric Data Property)
+ ```JSON
+{
+ "id": "Latitude",
+ "name": "Latitude",
+ "definition": "The angle between the equatorial plane and the straight line that passes through that point and through the center of the Earth determining how far north or south a location is",
+ "entityTypeID": "DataProperty",
+ "dataType": {
+ "entityTypeID": "DataType",
+ " id": "double"
+ },
+ "defaultUnit": {
+ "entityTypeID": "Unit",
+ " id": "degree"
+ },
+ "min": -180,
+ "max": 180
+}
+```
+#### Battery Type (Object Property)
+ ```JSON
+{
+ "id": "BatteryType",
+ "name": "Battery Type",
+ "definition": "A category of electric battery based on such things as the use of different metals and electrolytes",
+ "entityTypeID": "ObjectProperty",
+ "values": [
+ "LEAD_ACID",
+ "LITHIUM_COBALT_OXIDE",
+ "LITHIUM_ION_POLYMER",
+ "LITHIUM_IRON_PHOSPHATE",
+ "LITHIUM_MANGANESE",
+ "LITHIUM_TITANATE_OXIDE",
+ "NICKEL_METAL_HYDRIDE",
+ "OTHER",
+ "TERNARY_MATERIAL" ]
+}
+```
+
+## Scope
+
+### In Scope
+* Standardized schema for objects in the vehicle signal domain
+* Set of common objects in the vehicle signal domain
+
+### Out of Scope for Now
+ - Diagnostic signals
+
+### Out of Scope
+* Message formats and other implementation details
+
+
\ No newline at end of file
diff --git a/akm/documentation/content/schema/folder_strucure.md b/akm/documentation/content/schema/folder_strucure.md
new file mode 100755
index 0000000..03bbbf1
--- /dev/null
+++ b/akm/documentation/content/schema/folder_strucure.md
@@ -0,0 +1,24 @@
+
+
+---
+title: Folder Structure
+weight: 3
+---
+
+There are three main folders:
+
+- **\schema** contains the JSON Schema file(s) that provide the structure and meaning of the automotive metadata files
+
+- **\data** contains the JSON documents that contain the actual Automotive metadata
+
+- **\documentation** contains markdown files that explain aspects of the AKM, Content can be used for document generation using Hugo.
+
+
+Within the *data* folder, the AKM allows the following to be modified at will ***with no effect on validation, tooling, or other processes***:
+- the organization of folders and files within the tree
+- the names of folders and files
+- the inclusion of entries in each json file
+
+The initial release of the data folder contains sample data files and a subfolder for reference data.
+
+The repo is currently in an alpha release state and should be considered a **DRAFT**.
diff --git a/akm/documentation/content/usage/_index.md b/akm/documentation/content/usage/_index.md
new file mode 100755
index 0000000..3225440
--- /dev/null
+++ b/akm/documentation/content/usage/_index.md
@@ -0,0 +1,86 @@
+
+---
+title: Usage Guidelines
+weight: 40
+chapter: true
+---
+
+# Usage Guidelines
+
+## Partition Things / Reuse Properties
+Favor partitioning features of interest into their components rather than creating bespoke properties. For example, use this:
+```
+Seat.Row1.Left.IsOccupied
+Seat.Row1.Right.IsOccupied
+```
+...rather than this:
+```
+Seat.Is_Row1_Left_Occupied
+Seat.Is_Row1_Right_Occupied
+```
+This allows the property (*IsOccupied* in this example) to be defined once, providing a specific and consistent meaning. Also, models attain resilience when they represent reality. There is, in fact, a seat at the front left and front right. Those instances may acquire new properties. For example:
+```
+Seat.Row1.Left.FabricType
+Seat.Row1.Left.IsHeated
+```
+
+## Treat Signal Definitions as Optional
+The current customary practice is to assign a unique identifier to every signal. For metrics, every combination of feature of interest and property has its own identifier. This is analogous to the retail industry where every combination of size and color for a tee shirt has a unique stockkeeping unit (SKU). The retail industry requires this because they maintain inventory and order stock from several suppliers and require a system that works with all their items.
+
+Automotive information doesn't have those constraints. It's just digital information for which there is no inventory or resupply needs. There is an opportunity to use the more flexible approach used by taquerias, who would be crazy to offer a menu item for every combination of meat, rice, beans, and vegetable that a burrito could contain. Instead, the customer orders a burrito, and then selects from a list of ingredients.
+
+Systems would only need to maintain the sum of features of interest and properties:
+ ```YAML
+FeatureOfInterest: Seat.Row1.Left
+FeatureOfInterest: Seat.Row1.Right
+FeatureOfInterest: Seat.Row2.Left
+FeatureOfInterest: Seat.Row2.Right
+
+Property: IsOccupied
+Property: IsHeated
+Property: FabricType
+```
+...rather than the product:
+```
+Seat.Row1.Left.IsOccupied
+Seat.Row1.Right.IsOccupied
+Seat.Row2.Left.IsOccupied
+Seat.Row2.Right.IsOccupied
+
+Seat.Row1.Left.FabricType
+Seat.Row1.Right.FabricType
+Seat.Row2.Left.FabricType
+Seat.Row2.Right.FabricType
+
+Seat.Row1.Left.IsHeated
+Seat.Row1.Right.IsHeated
+Seat.Row2.Left.IsHeated
+Seat.Row2.Right.IsHeated
+```
+The detail moves to the payload of a generic metric object:
+ ```YAML
+Metric:
+ featureOfInterest: Seat.Row1.Left
+ property: IsOccupied
+ value: true
+```
+This lays the foundation for an even more compact model:
+ ```YAML
+FeatureOfInterest: Seat
+
+Property: IsOccupied
+Property: IsHeated
+Property: FabricType
+Property: CabinRow
+Property: LateralPosition
+```
+...in which metrics can identify specific instances when needed:
+ ```YAML
+Metric:
+ featureOfInterest: Seat
+ cabinRow: 1
+ lateralPosition: Left
+ property: IsOccupied
+ value: true
+ ```
+This is not meant to say that Metrics ***are*** optional. There are automotive standards for CAN bus and diagnostic codes that will stay embedded for some time. It may also be useful to explicitly declare which properties apply to which features of interest for enabling such things as authorization and privacy policies. The point is that conceiving of metrics as optional prepares for a future that eases the maintenance of vehicle metadata and allows the metadata to be understood and acted on by machines and algorithms.
diff --git a/akm/documentation/layouts/partials/favicon.html b/akm/documentation/layouts/partials/favicon.html
new file mode 100755
index 0000000..b530b23
--- /dev/null
+++ b/akm/documentation/layouts/partials/favicon.html
@@ -0,0 +1 @@
+
diff --git a/akm/documentation/layouts/partials/logo.html b/akm/documentation/layouts/partials/logo.html
new file mode 100755
index 0000000..c5f787c
--- /dev/null
+++ b/akm/documentation/layouts/partials/logo.html
@@ -0,0 +1,3 @@
+
+
+
diff --git a/akm/documentation/layouts/partials/menu-footer.html b/akm/documentation/layouts/partials/menu-footer.html
new file mode 100755
index 0000000..f98b47d
--- /dev/null
+++ b/akm/documentation/layouts/partials/menu-footer.html
@@ -0,0 +1,5 @@
+
+