diff --git a/text/0000-multiarch-builders-and-package.md b/text/0000-multiarch-builders-and-package.md
new file mode 100644
index 000000000..979bcf94d
--- /dev/null
+++ b/text/0000-multiarch-builders-and-package.md
@@ -0,0 +1,579 @@
+# Meta
+[meta]: #meta
+- Name: Multi-arch support for builders and buildpack packages
+- Start Date: 2023-09-14
+- Author(s): @jjbustamante
+- Status: Draft <!-- Acceptable values: Draft, Approved, On Hold, Superseded -->
+- RFC Pull Request: (leave blank)
+- CNB Pull Request: (leave blank)
+- CNB Issue: (leave blank)
+- Supersedes: (put "N/A" unless this replaces an existing RFC, then link to that RFC)
+
+# Summary
+[summary]: #summary
+
+The problem for adding support for multi-arch buildpacks can be divided into three parts:
+1. Support buildpack authors to **migrate their existing buildpacks** to support multi-arch.
+2. Support buildpack authors to **create new buildpacks and builders** that handle multi-arch from the beginning.
+3. Support application developers to **create application images** using multi-arch buildpacks and builders.
+
+The purpose of this RFC is to solve the statement 2, adding the capability to the commands:
+
+- `pack buildpack package`
+- `pack builder create`
+
+to create individuals OCI images artifacts per each os and arch (builders and buildpack packages) and handle the creation for the  [image index,](https://github.com/opencontainers/image-spec/blob/master/image-index.md)
+that combines them into one single consumable tag for end-users.
+
+# Definitions
+[definitions]: #definitions
+
+- Buildpack: A buildpack is a set of executables that inspects your app source code and creates a plan to build and run your application.
+- Builder: A builder is an image that contains all the components necessary to execute a build. A builder image is created by taking a build image and adding a lifecycle, buildpacks, and files that configure aspects of the build including the buildpack detection order and the location(s) of the run image
+- Image Manifest: The image manifest provides a configuration and set of layers for a single container image for a specific architecture and operating system. See [spec](https://github.com/opencontainers/image-spec/blob/main/manifest.md)
+- Image Index: The image index is a higher-level manifest which points to specific image manifests, ideal for one or more platforms. See [spec](https://github.com/opencontainers/image-spec/blob/main/image-index.md)
+
+# Motivation
+[motivation]: #motivation
+
+- Why should we do this?
+
+The uses of ARM architecture in the cloud and edge computing has been growing rapidly. The CNCF community has been also growing in the last years, and there is a need to support multi-arch for all the projects. The buildpacks community is not an exception, issues like:
+- [It would be nice to support easily creating a manifest list packages and builders](https://github.com/buildpacks/pack/issues/1460)
+- [Provide a way to specify desired platform when creating packages and builders](https://github.com/buildpacks/pack/issues/1459)
+- [Multi arch image build support](https://github.com/buildpacks/pack/issues/1570)
+
+Or the conversations around this topic in our [slack channel](https://cloud-native.slack.com/archives/C032LNSMY0P), even the [talk at Kubecon NA 2022](https://www.youtube.com/watch?v=Sdr5axlOnDI&list=PLj6h78yzYM2O5aNpRM71NQyx3WUe1xpTn&index=76) demonstrate the interest from the community in this feature.
+
+- What use cases does it support?
+
+Currently, buildpack authors can build and package their buildpacks for different OS and Architectures, but when they distribute them the URI for a buildpack can’t disambiguate, 
+they need to use different tags to differentiate between them. Tools like `docker buildx imagetools create` helps to create an [image index](https://github.com/opencontainers/image-spec/blob/master/image-index.md) to combine them but increasing their build pipelines complexity. 
+For example, take a look at this recent blog [post](https://deploy-preview-53--elegant-borg-5bd068.netlify.app/blog/steps-we-took-for-a-basic-arm64-support-in-buildpacks) or the [instructions](https://github.com/dmikusa/paketo-arm64/) created from @dmikusa to build an ARM64 builder.
+
+For those buildpack authors that are using `cross-compile` languages like [go](https://go.dev/) or [rust](https://www.rust-lang.org/) or maybe bash scripts, adding the capability to `pack buildpack package` and `pack builder create` to create multi-arch images 
+and also handle the creation of an [image index](https://github.com/opencontainers/image-spec/blob/master/image-index.md) will simplify their CI/CD pipelines and make the experience more suitable.
+
+- What is the expected outcome?
+
+`pack buildpack package` and `pack builder create` commands will be updated in a way that they will handle the creation of multi-arch OCI images
+
+# What it is
+[what-it-is]: #what-it-is
+
+The end-users for this proposal are **Buildpack authors**, we expect to improve their user experience when creating multi-architecture buildpacks and builders as follows
+
+## Multi-arch example
+
+Let's suppose a **Buildpack author** has a `buildpack.toml` created with a content similar to this one:
+
+```toml
+# Buildpack API version
+api = "0.12"
+
+# Buildpack ID and metadata
+[buildpack]
+  id = "examples/my-multiarch-buildpack"
+  version = "0.0.1"
+
+# List of targets operating systems, architectures and versions
+
+[[targets]]
+os = "linux"
+arch = "amd64"
+
+[[targets.distributions]]
+name = ""
+
+[[targets]]
+os = "linux"
+arch = "arm64"
+
+[[targets.distributions]]
+name = ""
+
+[[targets]]
+os = "windows"
+arch = "amd64"
+
+[[targets.distributions]]
+name = ""
+versions = ["10.0.20348.1970"]
+```
+
+And organizes the binaries according to their os/arch with a structure similar to this one:
+
+```bash
+my-multiarch-buildpack
+├── buildpack.toml
+├── linux-amd64
+│         └── bin
+│             ├── build
+│             └── detect
+├── linux-arm64
+│         └── bin
+│             ├── build
+│             └── detect
+└── windows-amd64
+    └── 10.0.20348.1970
+        └── bin
+            ├── build.bat
+            └── detect.bat
+```
+
+Now `pack` will be able to package them separately for each os/arch family, following our [guide](https://buildpacks.io/docs/buildpack-author-guide/package-a-buildpack/) 
+we will need to create a `package.toml` file.
+
+The `package.toml` file will be similar to the one describe in our documentation:
+
+```toml
+[buildpack]
+uri = "examples/my-multiarch-buildpack"
+# OR a .tgz with the previous folder structure
+uri = "my-multiarch-buildpack.tgz"
+```
+
+But in this case, we actually **remove** the [platform](https://buildpacks.io/docs/reference/config/package-config/) section because it will be taken from the `buildpack.toml`.
+
+Packaging a multi-arch buildpack will require the output to be **publish** to a registry or **saved on disk** in OCI layout format.
+
+```bash
+pack buildpack package my-buildpack --config ./package.toml --publish
+# Or
+pack buildpack package my-buildpack.cnb --config ./package.toml --format file
+```
+
+In these cases each `target` entry corresponds to a different buildpack image that is exported into an [image index](https://github.com/opencontainers/image-spec/blob/master/image-index.md)
+
+On the other hand, when a user exports the buildpack package into the docker daemon
+
+```bash
+pack buildpack package my-buildpack --config ./package.toml 
+```
+
+`pack` will not be able to create the [image index](https://github.com/opencontainers/image-spec/blob/master/image-index.md), and it will export the buildpack that corresponds to the `host` machine `os/arch`
+
+In case of packing a **Builder**, we assume the buildpack authors migrated their `builder.toml` and [remove the stack](https://github.com/buildpacks/pack/issues/1303) concept. 
+
+A sample `builder.toml` file looks like:
+
+```toml
+# Buildpacks to include in builder, these buildpacks MUST be multi-arch and point to Image Index
+[[buildpacks]]
+uri = "<some uri>"
+
+[run]
+# Runtime images - in case of multi-arch images it must point to Image Index
+[[run.images]]
+image = "index.docker.io/paketobuildpacks/run-jammy-tiny:latest"
+
+[build]
+# This image is used at build-time, in case of multi-arch images it must point to Image Index
+image = "docker.io/paketobuildpacks/build-jammy-tiny:0.2.3"
+```
+
+As we can see, the proposal is based on the assumption that the `run-image`, `build-image` and `buildpacks` to include in the builder are multi-arch artifacts, and we can reach them by reading an [image index](https://github.com/opencontainers/image-spec/blob/master/image-index.md)
+
+#### Package a multi-arch builder and publish it to a registry
+
+```bash
+pack builder create my-jammy-builder --config ./builder.toml \ 
+  --platform "linux/amd64" \ 
+  --platform "linux/arm64" \ 
+  --publish
+```
+
+In this case:
+
+`pack` will follow the builder creation process for **each provided platform**, pulling the correct (based on os/arch) buildpacks, build and run images and creating a different builder image that is exported into an [image index](https://github.com/opencontainers/image-spec/blob/master/image-index.md)
+
+## More examples
+
+For each example, let's suppose a `package.toml` exits and `pack buildpack package` command is invoke, we will show the expected output for each case.
+
+### Example 1
+
+folder structure:
+
+```bash
+├── bin
+│ ├── build
+│ └── detect
+├── buildpack.toml
+└── package.toml
+```
+
+`buildpack.toml`:
+
+```toml
+[[targets]]
+os = "linux"
+```
+
+Or
+
+```toml
+[[targets]]
+os = "linux"
+arch = "amd64"
+```
+
+Output:
+- **One** OCI image will be created with the provides `os/arch`
+- No [image index](https://github.com/opencontainers/image-spec/blob/master/image-index.md) will be created, only an [image manifest](https://github.com/opencontainers/image-spec/blob/main/manifest.md) 
+
+### Example 2
+
+folder structure:
+
+```bash
+├── bin
+│ ├── build
+│ └── detect
+├── buildpack.toml
+└── package.toml
+```
+
+`buildpack.toml`:
+
+```toml
+[[targets]]
+os = "linux"
+arch = "amd64"
+
+[[targets]]
+os = "linux"
+arch = "arm64"
+```
+
+Output:
+
+- **Two** OCI images will be created, **with the same content**, but their [configuration](https://github.com/opencontainers/image-spec/blob/main/config.md#properties) file will have different **architecture**  
+- An [image index](https://github.com/opencontainers/image-spec/blob/master/image-index.md) will be created 
+
+### Example 3 
+
+folder structure:
+
+```bash
+├── buildpack.toml
+├── linux-amd64
+│ └── bin
+│     ├── build
+│     └── detect
+├── linux-arm64
+│ └── bin
+│     ├── build
+│     └── detect
+└── package.toml
+```
+
+`buildpack.toml`:
+
+```toml
+[[targets]]
+os = "linux"
+arch = "amd64"
+
+[[targets]]
+os = "linux"
+arch = "arm64"
+```
+
+Output:
+
+- **Two** OCI images will be created, **with content** taken according to the `os/arch`
+- An [image index](https://github.com/opencontainers/image-spec/blob/master/image-index.md) will be created
+
+# How it Works
+[how-it-works]: #how-it-works
+
+<!--
+This is the technical portion of the RFC, where you explain the design in sufficient detail.
+
+The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.
+-->
+
+## Buildpack Package
+
+### Current `package.toml` structure
+
+The current schema for the [package.toml](https://buildpacks.io/docs/reference/config/package-config/) file
+
+```toml
+[buildpack]
+uri = "<some URL or path>"
+
+[extension]
+uri = "<some URL or path>"
+
+[[dependencies]]
+uri = "<some URL or path>" 
+image = "<some image ref>"
+
+[platform]
+os = "[linux|windows]"
+```
+
+```bash
+buildpack
+├── bin
+│   ├── build
+│   └── detect
+└── buildpack.toml
+```
+
+### New structure `package.toml` structure
+
+The proposal is to remove the `[platform]` section because that information can be taken from the `[targets]` in `buildpack.toml` 
+
+```toml
+[buildpack]
+uri = "<some URL or path>"
+
+[extension]
+uri = "<some URL or path>"
+
+[[dependencies]]
+uri = "<some URL or path>" 
+image = "<some image ref>"
+
+```
+
+#### buildpack.toml
+
+Based on the [RFC-0096](https://github.com/buildpacks/rfcs/blob/main/text/0096-remove-stacks-mixins.md) we replaced the concept of `stacks` in `buildpack.toml` by a `target` which looks like:
+
+```toml
+[[targets]]
+os = "<operating system>"
+arch = "<system architecture>"
+variant = "<architecture variant>"
+[[targets.distributions]]
+name = "<distribution ID>"
+versions = ["<distribution version>"]
+```
+
+The proposal is to use this information to infer a folder structure like the following:
+
+```bash
+.
+├── buildpack.toml
+└── {os}-{arch}             // optional
+    └── {variant}           // optional
+        ├── {version-1}     // optional
+        │   └── bin
+        │       ├── build
+        │       └── detect
+        └── {version-2}
+            └── bin
+                ├── build
+                └── detect
+```
+
+To determine where are the binaries and files that must exported to final OCI images according to their `os/arch`
+
+Preserving the following defaults:
+- If the `targets` list is empty and `/bin/build` is present
+    - A target with `os = "linux"` and `arch = "amd64"` is assumed by tools reading `buildpack.toml`.
+- If the `targets` list is empty and `/bin/build.bat` or `/bin/build.exe` is present
+    - A target with `os = "windows"` and `arch = "amd64"` is assumed by tools reading `buildpack.toml`.
+
+## Builder
+
+
+# Migration
+[migration]: #migration
+
+<!--
+This section should document breaks to public API and breaks in compatibility due to this RFC's proposed changes. In addition, it should document the proposed steps that one would need to take to work through these changes. Care should be give to include all applicable personas, such as platform developers, buildpack developers, buildpack users and consumers of buildpack images.
+-->
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+<!--
+Why should we *not* do this?
+-->
+
+# Alternatives
+[alternatives]: #alternatives
+
+<!--
+- What other designs have been considered?
+- Why is this proposal the best?
+- What is the impact of not doing this?
+-->
+
+# Prior Art
+[prior-art]: #prior-art
+
+- This RFC is a continuation of the work started with the proposal to add commands to handle manifest list in pack, see the [RFC](https://github.com/buildpacks/rfcs/pull/283)
+- Paketo [RFC #288](https://github.com/paketo-buildpacks/rfcs/pull/288) to publish multi-arch buildpacks
+
+# Unresolved Questions
+[unresolved-questions]: #unresolved-questions
+
+> **Note**
+> These are some questions I need to answer
+>
+> What are the intermediate images for each platform named/called? What happens if you don't put --append here? (from Terence)
+>
+> What happen if my binaries are the same for every os/arch, do I have to copy all the files?
+>
+> What happen if I want to exclude some buildpack for a particular target?
+>
+> What happen if I want to include the same file or folder for every image, do I have to copy then inside the {os}-{arch} folder?
+
+
+<!--
+- What parts of the design do you expect to be resolved before this gets merged?
+- What parts of the design do you expect to be resolved through implementation of the feature?
+- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?
+-->
+
+# Spec. Changes (OPTIONAL)
+[spec-changes]: #spec-changes
+
+<!--
+Does this RFC entail any proposed changes to the core specifications or extensions? If so, please document changes here.
+Examples of a spec. change might be new lifecycle flags, new `buildpack.toml` fields, new fields in the buildpackage label, etc.
+This section is not intended to be binding, but as discussion of an RFC unfolds, if spec changes are necessary, they should be documented here.
+-->
+
+# History
+[history]: #history
+
+<!--
+## Amended
+### Meta
+[meta-1]: #meta-1
+- Name: (fill in the amendment name: Variable Rename)
+- Start Date: (fill in today's date: YYYY-MM-DD)
+- Author(s): (Github usernames)
+- Amendment Pull Request: (leave blank)
+
+### Summary
+
+A brief description of the changes.
+
+### Motivation
+
+Why was this amendment necessary?
+--->
+
+
+<!--
+
+[[dependencies]]
+uri = "samples/buildpacks/hello-moon"
+
+[[dependencies]]
+uri = "docker://cnbs/sample-package:hello-world"
+
+[[dependencies.ignore.targets]]
+os = "linux"
+arch = "amd64"
+[[dependencies.ignore.targets]]
+name = "ubuntu"
+versions = ["14.04", "16.04"]
+
+
+
+[buildpack]
+uri = "samples/buildpacks/hello-universe/"
+
+[[dependencies]]
+uri = "samples/buildpacks/hello-moon"
+
+[[dependencies]]
+uri = "docker://cnbs/sample-package:hello-world"
+
+[config]
+reuse-binaries = "true"
+
+
+
+URI Examples 
+A path to a directory†, tar file, or tgz file
+
+./my/buildpack/
+./my/buildpack.tgz
+/home/user/my/buildpack.tgz
+file:///my/buildpack.tgz
+file:///home/user/my/buildpack.tgz
+A URL to a tar or tgz file containing a buildpackage
+
+http://example.com/my/buildpack.tgz
+https://example.com/my/buildpack.tgz
+A Docker image containing a buildpackage
+
+docker://gcr.io/distroless/nodejs
+docker:///ubuntu:latest
+docker:///ubuntu@sha256:45b23dee08...
+A buildpack located in a CNB Builder
+
+urn:cnb:builder:bp.id
+urn:cnb:builder:bp.id@bp.version
+A buildpack located in a CNB Registry
+
+urn:cnb:registry:bp-id
+urn:cnb:registry:bp-id@bp.version
+
+-->
+
+
+
+<!--
+Reading the `buildpack.toml` file, `pack` will determine:
+- There are 3 targets available
+- For each target, the root path for the buildpack can be determined by concatenating `target.os/target.arch[/target.variant]`
+  - If `target.versions` are available
+    - For each **version** in `target.versions`
+        - buildpack root path will be `target.os/target.arch[/target.variant]/version`
+  - Each root path corresponds to a different buildpack image that is exported into a [image index](https://github.com/opencontainers/image-spec/blob/master/image-index.md)
+
+
+- `pack` will determine the `host` machine `os/arch`
+- `pack` will determine there are 3 targets available, after reading the `buildpack.toml` file
+- For each target
+  - `pack` will search a target that matches: `host.os == target.os` AND `host.arch == target.os` 
+    - `pack` calculate the root path similar as describe above, but only for this target
+- `pack` will save the buildpack at the determined root path as an image in the daemon as it is doing it today
+
+--> 
+
+
+<!--
+and every `build`, `run` images and declared `buildpacks` must be addressable by an [image index](https://github.com/opencontainers/image-spec/blob/master/image-index.md) 
+
+This provides a high level overview of the feature.
+
+- Define any new terminology.
+- Define the target persona: buildpack author, buildpack user, platform operator, platform implementor, and/or project contributor.
+- Explaining the feature largely in terms of examples.
+- If applicable, provide sample error messages, deprecation warnings, or migration guidance.
+- If applicable, describe the differences between teaching this to existing users and new users.
+
+The following sections describe the functionality with some examples
+
+### Set up the buildpack scaffolding
+
+Let's use our buildpack author [guide](https://buildpacks.io/docs/buildpack-author-guide/create-buildpack/building-blocks-cnb/) and create a new filesystem structure to handle a multi-arch buildpack.
+
+Specifies the platform in the form os/arch[/variant][:osversion] 
+
+```bash
+pack buildpack new examples/my-multiarch-buildpack \
+--api 0.12 \
+--path my-multiarch-buildpack \
+--version 0.0.1 \
+--platform "linux/amd64" --platform "linux/arm64" --platform "windows/amd64:10.0.20348.1970"
+```
+
+This command will create `my-multiarch-buildpack` directory which contains `buildpack.toml` and folders for the different `os/arch[/variant]:[osversion]` defined by the user and
+`bin/build`, `bin/detect` files inside these folders.
+
+
+-->
+