diff --git a/profiles/rcord/configuration.md b/profiles/rcord/configuration.md
index 4e81cb0..67f59ee 100644
--- a/profiles/rcord/configuration.md
+++ b/profiles/rcord/configuration.md
@@ -223,275 +223,3 @@
 
 For instructions on how to push TOSCA into a CORD POD, please
 refer to this [guide](../../xos-tosca/README.md).
-
-## Zero-Touch Subscriber Provisioning
-
-This feature, also referred to as "bottom-up" provisioning,
-enables auto-discovery of subscribers and validates them
-using an external OSS.
-
-The expected workflow is as follows:
-
-- When an ONU is attached to the POD, VOLTHA will discover it and send
-   an event to XOS
-- XOS receives the ONU activation event and through an OSS proxy
-   queries the upstream OSS to validate wether that ONU has a valid serial number
-- Once the OSS has approved the ONU, XOS will create `ServiceInstance`
-  chain for this particular subscriber and configure the POD to enable connectivity
-
-To enable the zero-touch provisioning feature, you will need to deploy
-and configure some extra pieces into the system before attaching
-subscribers:
-
-### Deploy Kafka
-
-To enable this feature XOS needs to receive events from `onos-voltha`,
-so a kafka bus needs to be deployed.
-To deploy Kafka, please follow these [instructions](../../charts/kafka.md)
-
-### Deploy OSS Proxy
-
-This is the piece of code that is responsible to connecting CORD to an
-external OSS Database. As a simple reference, we provide a sample
-implemetation, available here:
-[hippie-oss](https://github.com/opencord/hippie-oss)
-
-> **Note:** This implementation currently validates any subscriber that comes online.
-
-To deploy the `hippie-oss` service you can look [here](../../charts/hippie-oss.md).
-
-Once the chart has come online, you will need to add the Hippie-OSS service
-to your service graph. You can use the following TOSCA to do that:
-
-```yaml
-tosca_definitions_version: tosca_simple_yaml_1_0
-imports:
-  - custom_types/hippieossservice.yaml
-  - custom_types/servicedependency.yaml
-  - custom_types/voltservice.yaml
-description: Create an instance of the OSS Service and connect it to the vOLT Service
-topology_template:
-  node_templates:
-
-    # Reference the VOLTService
-    service#volt:
-      type: tosca.nodes.VOLTService
-      properties:
-        name: volt
-        must-exist: true
-
-    # Reference the HippieOSSService
-    service#oss:
-      type: tosca.nodes.HippieOSSService
-      properties:
-        name: hippie-oss
-        kind: oss
-        # blacklist: BRCM1234, BRCM4321 # this is an optional list of ONUs that you don't want to validate
-
-    # Create a ServiceDependency between the two
-    service_dependency#oss_volt:
-      type: tosca.nodes.ServiceDependency
-      properties:
-        connect_method: None
-      requirements:
-        - subscriber_service:
-            node: service#oss
-            relationship: tosca.relationships.BelongsToOne
-        - provider_service:
-            node: service#volt
-            relationship: tosca.relationships.BelongsToOne
-```
-
-For instructions on how to push TOSCA into a CORD POD, please
-refer to this [guide](../../xos-tosca/README.md).
-
-### Complete the Subscriber config
-
-As a result of the OLT/ONU activation you'll find out that XOS has generated
-an `RCORDSubscriber` for you.
-That model has the `status` field set to `awaiting-auth`, that means that
-you can ping the gateway but not the internet.
-
-The authentication mechanism is not yet ready in CORD 6.0,
-so you need to configure few attributes manully,
-such as:
-
-- `ip_addres`
-- `mac_address`
-- set `status` to `enabled`
-
-You can do that via the GUI or you can use a TOSCA like the following:
-```yaml
-tosca_definitions_version: tosca_simple_yaml_1_0
-imports:
-  - custom_types/rcordsubscriber.yaml
-description: Create a test subscriber
-topology_template:
-  node_templates:
-    # A subscriber
-    my_house:
-      type: tosca.nodes.RCORDSubscriber
-      properties:
-        name: My House
-        must-exist: true
-        status: enabled
-        mac_address: 00:AA:00:00:00:01 # subscriber mac address
-        ip_address: 10.8.2.1 # subscriber IP
-```
-
-For instructions on how to push TOSCA into a CORD POD, please
-refer to this [guide](../../xos-tosca/README.md).
-
-#### Pre-provision subscribers
-
-Another viable approach is to `pre-provision` subscribers,
-you can do that using this TOSCA:
-
-```yaml
-tosca_definitions_version: tosca_simple_yaml_1_0
-imports:
-  - custom_types/rcordsubscriber.yaml
-
-description: Pre-provsion a subscriber
-
-topology_template:
-  node_templates:
-
-    # Pre-provision the subscriber the subscriber
-    my_house:
-      type: tosca.nodes.RCORDSubscriber
-      properties:
-        name: My House
-        status: pre-provisioned
-        c_tag: 111
-        onu_device: BRCM22222222
-        mac_address: 90:E2:BA:82:FA:81
-        ip_address: 192.168.0.1
-```
->NOTE: if you do this you still need to set `status=enabled` after the ONU comes up
-
-For instructions on how to push TOSCA into a CORD POD, please
-refer to this [guide](../../xos-tosca/README.md).
-
-### Know issues
-
-There is a set of issue that we have seen from time to time.
-They are currently undergoing a deeper investigation, but here is how to identify
-and correct them.
-
-#### OLTDevices are not pushed to VOLTHA
-
-If you have configured OLTDevices in XOS and you are not seeing them in VOLTHA,
-you should check the vOLT-synchronizer logs:
-
-```shell
-kubectl logs -f $(kubectl get pods | grep volt- | awk '{print $1}')
-```
-
-If the logs are not moving, restart the synchronizer:
-
-```shell
-kubectl delete pod $(kubectl get pods | grep volt- | awk '{print $1}')
-```
-
-#### ONU Activate events are not received by XOS
-
-Once OLTs have been activated, XOS should receive events and create
-`HippieOssServiceInstance` models for each event.
-
-To check if XOS has been received from XOS you can use this command:
-
-```shell
-kubectl logs -f $(kubectl get pods | grep volt- | awk '{print $1}') | grep "onu.event"
-```
-
-If the events have been received you should see something like:
-
-```shell
-Processing event               msg=ConsumerRecord(topic=u'onu.events', partition=0, offset=42, timestamp=1530296353275, timestamp_type=0, key=None, value='{"timestamp":1530296353275,"status":"activated","serial_number":"ALPHe3d1cfde","uni_port_id":48,"of_dpid":"of:000000000a5a0097"}', checksum=100437027, serialized_key_size=-1, serialized_value_size=128) step=ONUEventStep
-onu.events: received event     value={u'status': u'activated', u'timestamp': 1530296353275, u'uni_port_id': 48, u'of_dpid': u'of:000000000a5a0097', u'serial_number': u'ALPHe3d1cfde'}
-onu.events: activate onu       value={u'status': u'activated', u'timestamp': 1530296353275, u'uni_port_id': 48, u'of_dpid': u'of:000000000a5a0097', u'serial_number': u'ALPHe3d1cfde'}
-onu.events: Calling OSS for ONUDevice with serial_number ALPHe3d1cfde
-```
-
-If you don't see that, you can force ONOS-VOLTHA to send the events again.
-
-Connect to the ONOS-VOLTHA CLI:
-
-```shell
-ssh karaf@<pod-ip> -p $(kubectl get svc -n voltha | grep -i onos-voltha-ssh |  awk '{print substr($5,6,5)}')
-```
-Remove the device:
-
-```shell
-onos> device-remove <device-ofid>
-```
-
-The device will be automatically discovered again, and events are sent.
-
-##### Check if the events appears in Kafka
-
-If you are still not seeing the events in XOS, you can check if they appear into Kafka.
-
-To do that `exec` into any synchronizer container:
-
-```shell
-kubectl exec -it $(kubectl get pods | grep volt- | awk '{print $1}') bash
-apt-get update
-apt-get install kafkacat -y
-kafkacat -b cord-kafka.default.svc.cluster.local:9092 -t onu.events
-```
-
-If the events have reached `kafka` you should see this message:
-
-```shell
-{"timestamp":1530301582776,"status":"activated","serial_number":"ALPHe3d1cfde","uni_port_id":48,"of_dpid":"of:000000000a5a0097"}
-```
-
-If they have not you are probably missing the correct configuration in ONOS-VOLTHA,
-to verify that, ssh into ONOS-VOLTHA:
-
-```shell
-ssh karaf@<pod-ip> -p $(kubectl get svc -n voltha | grep -i onos-voltha-ssh |  awk '{print substr($5,6,5)}')
-```
-
-and check if there is any configuration for the `org.opencord.olt` app:
-
-```shell
-onos> netcfg apps org.opencord.olt
-{
-  "kafka" : {
-    "bootstrapServers" : "cord-kafka.default.svc.cluster.local:9092"
-  }
-}
-```
-
-If you don't have that configuration, you can resubmit it by going into the XOS-GUI,
-search for `ServiceInstanceAttributes` and save the configuration again.
-
-#### Subscribers are not created as a result of an ONU Activate event
-
-If you see `HippieOssServiceInstances` but you don't see any `Subscriber` in XOS,
-you should check if the model policies for the `HippieOssServiceInstances` have been executed:
-
-```shell
-kubectl logs -f $(kubectl get pods | grep hippie- | awk '{print $1}') | grep -i "model_policy"
-```
-
-I this is the only line you are seeing:
-
-```shell
-Loaded model policies          policies=[<class 'model_policy_hippieossserviceinstance.OSSServiceInstancePolicy'>]
-```
-
-Go to the XOS-GUI, search for `HippieOssServiceInstances` and save them again.
-You should see the above command print more logs and `Subscriber`s beeing created.
-
-#### ONU Ports are down
-
-If everything is correctly configured across the POD, but you can't ping
-the gateway from your client, it's possible that the ports on the ONU are not up.
-
-Assuming that your client is connected to the OLT via the interface `eth1`,
-you can check if the client sees the port as up or not. If the port is not up,
-reboot the ONU.
diff --git a/profiles/rcord/workflows/att.md b/profiles/rcord/workflows/att.md
index 79545ea..c416b8a 100644
--- a/profiles/rcord/workflows/att.md
+++ b/profiles/rcord/workflows/att.md
@@ -2,6 +2,24 @@
 
 You can find a complete description of the SEBA workflow for At&t in [this document](https://docs.google.com/document/d/1nou2c8AsRzhaDJmA_eYvFgd0Y33KiCsioveU77AOVCI/edit#heading=h.x73smxj2xaib). This pages focus exclusively on the internals details of the workflow such as actions triggered by the environment and decisions taken by NEM.
 
+## Helm charts
+
+To replicate this workflow you'll need to install:
+
+- [xos-core](../../../charts/xos-core.md)
+- [cord-kafka](../../../charts/kafka.md)
+- [voltha-kafka](../../../charts/voltha.md)
+- [voltha](../../../charts/voltha.md)
+- [onos-voltha](../../../charts/onos.md#onos-voltha)
+- [onos-fabric](../../../charts/onos.md#onos-fabric)
+- att-workflow
+
+### Install the `att-workflow` chart
+
+```shell
+helm install -n att-workflow xos-profiles/att-workflow
+```
+
 ## Workflow description
 
 1. ONT discovered bottom-up
@@ -27,4 +45,110 @@
 
 ![att-workflow](../../../images/att_workflow.png)
 
-> NOTE: when we refer to `service chain` we are talking about the set of subscriber specific service instances that will trigger the `add_subscriber` call in ONOS-VOLTHA and provision the crossconnect in ONOS-FABRIC
\ No newline at end of file
+> NOTE: when we refer to `service chain` we are talking about the set of
+subscriber specific service instances that will trigger the `add_subscriber`
+call in ONOS-VOLTHA and provision the crossconnect in ONOS-FABRIC
+
+## Operations
+
+We assume your POD is already configured as per[this instructions](../configuration.md)
+(you need to complete only the first section)
+
+### Whitelist population
+
+To configure the ONU whitelist, you can use this TOSCA:
+
+```yaml
+tosca_definitions_version: tosca_simple_yaml_1_0
+imports:
+  - custom_types/attworkflowdriverwhitelistentry.yaml
+  - custom_types/attworkflowdriverservice.yaml
+description: Create an entry in the whitelist
+topology_template:
+  node_templates:
+
+    service#att:
+      type: tosca.nodes.AttWorkflowDriverService
+      properties:
+        name: att-workflow-driver
+        must-exist: true
+
+    whitelist:
+      type: tosca.nodes.AttWorkflowDriverWhiteListEntry
+      properties:
+        serial_number: BRCM22222222
+      requirements:
+        - owner:
+            node: service#att
+            relationship: tosca.relationships.BelongsToOne
+```
+
+For instructions on how to push TOSCA into a CORD POD, please
+refer to this [guide](../../../xos-tosca/README.md).
+
+### Pre-provision subscribers
+
+You can `pre-provision` subscribers using this TOSCA:
+
+```yaml
+tosca_definitions_version: tosca_simple_yaml_1_0
+imports:
+  - custom_types/rcordsubscriber.yaml
+
+description: Pre-provsion a subscriber
+
+topology_template:
+  node_templates:
+
+    # Pre-provision the subscriber the subscriber
+    my_house:
+      type: tosca.nodes.RCORDSubscriber
+      properties:
+        name: My House
+        status: pre-provisioned
+        c_tag: 111
+        onu_device: BRCM22222222
+```
+
+For instructions on how to push TOSCA into a CORD POD, please
+refer to this [guide](../../../xos-tosca/README.md).
+
+### OLT Activation
+
+Once the system knows about whitelisted ONUs and subscribers,
+you can activate the OLT:
+
+```yaml
+tosca_definitions_version: tosca_simple_yaml_1_0
+imports:
+  - custom_types/oltdevice.yaml
+  - custom_types/voltservice.yaml
+description: Create a simulated OLT Device in VOLTHA
+topology_template:
+  node_templates:
+
+    service#volt:
+      type: tosca.nodes.VOLTService
+      properties:
+        name: volt
+        must-exist: true
+
+    olt_device:
+      type: tosca.nodes.OLTDevice
+      properties:
+        name: ONF OLT
+        device_type: openolt
+        host: 10.90.0.114
+        port: 9191
+        switch_datapath_id: of:0000000000000001
+        switch_port: "1"
+        outer_tpid: "0x8100"
+        uplink: "128"
+      requirements:
+        - volt_service:
+            node: service#volt
+            relationship: tosca.relationships.BelongsToOne
+```
+
+For instructions on how to push TOSCA into a CORD POD, please
+refer to this [guide](../../../xos-tosca/README.md).
\ No newline at end of file
diff --git a/styles/website.css b/styles/website.css
index 62fe48f..0957a64 100644
--- a/styles/website.css
+++ b/styles/website.css
@@ -1,5 +1,5 @@
 .page-inner {
-    max-width: 95% !important;
+    max-width: 85% !important;
 }
 
 .page-toc {