+The, almost, complete data model for CAPIF is shown in the diagram below.
+
+<img src="docs/diagrams/Information model for CAPIF.svg">
+
+The data used within CAPIF Core for registering rApps that both provides and consumes services is shown in the diagram below.
+
+<img src="docs/diagrams/Information in rApp registration.svg">
+
+Some examples of interactions between components using the CAPIF interface are shown in the sequence diagram below.
+
+***NOTE!*** It has not been decided that CAPIF Core will actually do the Helm chart installation. This is just provided in the prototype as an example of what CAPIF Core could do.
+
+<img src="docs/diagrams/Register Provider.svg">
+
+If Helm is used, before publishing a service, the chart that belongs to the service must be registered in ChartMuseum. When publishing the service the following information should be provided in the `ServiceAPIDescription::description` attribute; "namespace", "repoName", "chartName", "releaseName". An example of the information: "Description of rApp helloWorld,namespace,repoName,chartName,releaseName".
+
+## Generation of API code
+
+The CAPIF APIs are generated from the OpenAPI specifications provided by 3GPP. The `generate.sh` script downloads the
+specifications from 3GPP, fixes them and then generates the APIs. It also generates the mocks needed for unit testing.
+The specifications are downloaded from the following site; https://www.3gpp.org/ftp/Specs/archive/29_series. To see
+the APIs in swagger format, see the following link; https://github.com/jdegre/5GC_APIs/tree/Rel-16#common-api-framework-capif.
+**NOTE!** The documentation in this link is for release 16 of CAPIF, the downloaded specifications are for release 17.
+
+To fix the specifications there are three tools:
+- `commoncollector`, collects type definitions from peripheral specifications to keep down the number of dependencies to
+ other specifications. The types to collect are listed in the `definitions.txt`file. Some fixes are hard coded.
+- `enumfixer`, fixes enumeration definitions so they can be properly generated.
+- `specificationfixer`, fixes flaws in the specifications so they can be properly generated. All fixes are hard coded.
+
+### Steps to add a new dependency to the commoncollector
+
+When a dependency to a new specification is introduced in any of the CAPIF specifications, see example below, the following steps should be performed:
+
+For the CAPIF specification "TS29222_CAPIF_Discover_Service_API" a new dependency like the following has been introduced.
+
+ websockNotifConfig:
+ $ref: ✅TS29122_CommonData.yaml#/components/schemas/WebsockNotifConfig✅'