+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 an rApp that both provides and consumes services is shown in the diagram below.
+
+<img src="docs/diagrams/Information in rApp registration.svg">
+
+An example of how an rApp that both provides and consumes services can be registered in CAPIF Core is shown in the sequence diagram below. Discovery of services, request for access token and event subscription for an invoker is also shown.
+
+***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✅'