diff --git a/.github/ISSUE_TEMPLATE/core-project.md b/.github/ISSUE_TEMPLATE/core-project.md
new file mode 100644
index 0000000..4cd5d46
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/core-project.md
@@ -0,0 +1,298 @@
+---
+name: "New Core Project"
+about: "Propose the promotion of a hosted project to a core project."
+title: "Core Project Proposal: The TODO Project"
+labels: "core-project-proposal"
+assignees: ""
+---
+
+Proposing the promotion of TODO to a core project.
+
+Repository URL: TODO
+
+TODO: One paragraph describing what the project is, what its goals are, and etc...
+
+## Requirements
+
+### Alignment with the Bytecode Alliance Mission
+
+> Projects must have alignment with [the Bytecode Alliance mission:](https://github.com/bytecodealliance/governance/blob/main/mission.md)
+>
+> > Our mission is to provide state-of-the-art foundations to develop runtime environments and language toolchains where security, efficiency, and modularity can all coexist across a wide range of devices and architectures. We enable innovation in compilers, runtimes, and tooling, focusing on fine-grained sandboxing, capabilities-based security, modularity, and standards such as WebAssembly and WASI.
+>
+> The Bytecode Alliance is a group with a specific mission, and we therefore will only sponsor projects that are in alignment with and further that mission. For example, project sponsorship is untenable if the project undermines sandboxing, security, or standardization efforts.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Changelog
+
+> Core projects must highlight key additions, breaking changes, security fixes, and otherwise noteworthy changes in a changelog.
+>
+> See [keepachangelog.com](https://keepachangelog.com/en/1.1.0/) for a recommended approach.
+>
+> We are building an ecosystem that developers can depend on, and one small part of that is communicating important changes downstream.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Code Review
+
+> All projects must gate merging pull requests on code reviews that audit not only for style but also substance, such as whether security invariants are properly maintained by the new code.
+>
+> Core projects must maintain [a `CODEOWNERS` file](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) and use it to automatically assign reviewers to pull requests. Auto-assigned reviewers must respond to pull requests in a timely fashion. However, that response doesn't have to be a full code review; it could also be
+>
+> - "I intend to review this but I can't immediately. Please leave me a message if I haven't responded by `$SPECIFIC_DATE_IN_NEAR_FUTURE`."
+> - "I think `$SPECIFIC_OTHER_MAINTAINER` should review this." (Note that the best reviewer for a PR may not necessarily be listed in the `CODEOWNERS` file.)
+>
+> Code reviews have a demonstrable impact on the quality of source code by catching bugs early, determining the best possible implementation, and fostering trust within the community. Timely responses let contributors know that their work is valued and encourages further contribution.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Code of Conduct
+
+> All Bytecode Alliance projects must:
+>
+> * link to the Bytecode Alliance's Code of Conduct documents from a `CODE_OF_CONDUCT.md` file in root of the repository, and
+> * enforce the codes of conduct among the community and contributors, or escalate to [the Bytecode Alliance CoC Team](mailto:report@bytecodealliance.org), if needed.
+>
+> Having a code of conduct is crucial for creating a positive and respectful environment in any organization, community, or group. It serves as a set of guidelines that outline expected behavior and ethical standards for all members involved.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Continuous Fuzzing
+
+> Not all projects will necessarily benefit from fuzzing, for example benchmark suites. The TSC may choose lift this requirement for a particular project.
+>
+> It is required that core projects have continuous fuzzing, for example in [OSS-Fuzz](https://github.com/google/oss-fuzz). The fuzzing must exercise significant amounts of the code base and test the project's most important properties, such as sandboxing. Bugs and vulnerabilities discovered via fuzzing must be addressed promptly.
+>
+> Part of our open-source and open contribution model, the corpus and setup for running fuzzing must be open-sourced as part of the project.
+>
+> Faults discovered via fuzzing must be reported privately to the project's core team so that the project's security vulnerability process can be followed properly, if necessary. For example, fuzzing infrastructure must not automatically open public issues for any fault that is discovered.
+>
+> Continuous fuzzing is a valuable practice for projects, due to its significant benefits in improving security and reliability. Within the Bytecode Alliance, we host projects that provide a sandbox. The fidelity of these sandboxes must be battle-tested via a number of methodologies including automated fuzzing.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Continuous Integration Testing
+
+> All projects must run continuous integration (CI) tests on all pull requests and merges. Key project features must be covered by CI.
+>
+> If any part of the CI gates on merging changes that is not reproducible by external contributors, then the project must make affordances to support those external contributors.
+>
+> Implementing CI offers several benefits to software projects, helping ensure correctness and quality, making it an essential practice for modern software development.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Contributor Documentation
+
+> All projects must have a `CONTRIBUTING.md` document in the root of their repository. This document must provide, or link to another form of project-specific documentation that provides, high-quality contributor documentation.
+>
+> See ["How to build a `CONTRIBUTING.md`" by the Mozilla Science Lab](https://mozillascience.github.io/working-open-workshop/contributing/) for more details on what a high-quality `CONTRIBUTING.md` file looks like.
+>
+> A `CONTRIBUTING.md` serves as a guide for potential contributors, outlining the expectations for individuals who wish to contribute to the project. The Bytecode Alliance is a community-driven software foundation and documents like `CONTRIBUTING.md` are necessary for fostering community contributions.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### End-User Documentation
+
+> We abide by [the OpenSSF requirements for documentation](https://bestpractices.coreinfrastructure.org/en):
+>
+> > The documentation of an external interface explains to an end-user or developer how to use it. This would include its application program interface (API) if the software has one. If it is a library, document the major classes/types and methods/functions that can be called. If it is a web application, define its URL interface (often its REST interface). If it is a command-line interface, document the parameters and options it supports. In many cases it's best if most of this documentation is automatically generated, so that this documentation stays synchronized with the software as it changes, but this isn't required. The project MAY use hypertext links to non-project material as documentation. Documentation MAY be automatically generated (where practical this is often the best way to do so).
+>
+> Furthermore, we identify a few different types of (sometimes overlapping) documentation:
+>
+> * **API documentation**: Documentation for each type, method, function, and module in a library.
+> * **Architectural overviews**: High-level documentation about the architecture of the project and how it works from a 1000-foot view that helps endusers take advantage of the project in the best way possible and helps onboard new contributors.
+> * **Examples**: Code examples that show off how to use the project as a whole or particular features it supports.
+> * **Guides and tutorials**: Long-form prose, with code samples interspersed, that shows how to accomplish a task using the project.
+>
+> All of the above types of documentation are required for core projects.
+>
+> Documentation is necessary for end-users to productively use the project; source code comments are not sufficient.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Following the Bytecode Alliance Operational Principles
+
+> All projects must follow [the Bytecode Alliance Operational Principles](https://github.com/bytecodealliance/governance/blob/main/operational-principles.md).
+>
+> In pursuing our mission and vision, the Bytecode Alliance follows a set of operational principles aimed at keeping us aligned on three key aspects: what we want to create, how we want to work together, and how we want to work with others.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Issue Triage Process
+
+> Core projects must use an issue tracker for tracking individual issues.
+>
+> Core projects must have a documented process for expeditiously triaging incoming issues and pull requests, and follow that process. Contributors should get prompt responses to their issues and pull requests, even if a response is not an immediate fix or review.
+>
+> For a successful community-driven project, expedient communication within issues and PRs encourages further collaboration and contribution.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Leverage the Bytecode Alliance RFC Process
+
+> A request for comments (RFC) is a technique for soliciting the community and contributors for feedback on proposed major changes and decisions.
+>
+> Core projects must follow [the Bytecode Alliance RFC process](https://github.com/bytecodealliance/rfcs/blob/main/accepted/rfc-process.md) for changes that significantly affect project stakeholders or contributors. The RFCs repo describes [when an RFC is needed](https://github.com/bytecodealliance/rfcs/#when-is-an-rfc-needed) in more detail:
+>
+> > Many changes to Bytecode Alliance projects can and should happen through every-day GitHub processes: issues and pull requests. An RFC is warranted when:
+> >
+> > * The work involves changes that will significantly affect stakeholders or project contributors. Each project may provide more specific guidance. Examples include:
+> >     * Major architectural changes
+> >     * Major new features
+> >     * Simple changes that have significant downstream impact
+> >     * Changes that could affect guarantees or level of support, e.g. removing support for a target platform
+> >     * Changes that could affect mission alignment, e.g. by changing properties of the security model
+> > * The work is substantial and you want to get early feedback on your approach.
+>
+> This is a best practice for aligning contributors, the community, and downstream project's needs with proposed technical implementations.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Licensing Compatible with the Bytecode Alliance
+
+> All projects must be licensed under the Apache 2.0 license with an LLVM exception. Exemptions may be granted by the board.
+>
+> All projects must only use dependencies and third-party code licensed under one of the following open source licenses:
+>
+> * Apache-2.0 WITH LLVM-exception
+> * Apache-2.0
+> * BSD-2-Clause
+> * BSD-3-Clause
+> * ISC
+> * MIT
+> * MPL-2.0
+> * OpenSSL
+> * Unicode-DFS-2016
+> * Zlib
+>
+> All dependencies and third-party code must be properly attributed.
+>
+> The source for all projects must be available to all members and must be available to all non-members under the same license.
+>
+> All projects must automatically ensure that licensing requirements of dependencies are met in CI.
+>
+> We strive to build an open community and a legally-compatible software ecosystem.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Production Use
+
+> Core projects must have demonstrated use in production by at least three independent organizations which are, in the TSC's judgement, of adequate quality and scope.
+>
+> It is recommended that projects track production usage by organizations in an `ADOPTERS.md` at the root of the project, for example see [`ADOPTERS.md`](https://github.com/bytecodealliance/wasmtime/blob/main/ADOPTERS.md) in Wasmtime.
+>
+> In order to become a core project, that project must demonstrate that it is practical, useful, and reliable enough to use in production.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Public Project Meetings and Notes
+
+> Core projects must hold regular and public project meetings. Meeting times and frequency must be advertised publicly, for example in the project's `CONTRIBUTING.md`. To avoid spam and "Zoom bombing", the video conferencing link need not be public, but must be available upon request.
+>
+> Agendas for upcoming meetings and notes from past meetings must be published publicly. The notes should be in the `bytecodealliance/meetings` repository.
+>
+> Public meetings encourage open communication, collaboration, and engagement within the project's community. Notes allow community members who were not present to remain aligned and can document any decisions made during the meeting.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### README
+
+> All projects must have a `README.md` file in the root of the repository which begins with:
+>
+> * The project name and logo (if one exists)
+> * A one-sentence description of the project
+> * `<strong>A <a href="https://bytecodealliance.org/">Bytecode Alliance</a> core project</strong>`
+>
+> The most important information about the project should be "above the fold". Projects should identify themselves as Bytecode Alliance projects so that with time they associate the Bytecode Alliance with quality projects that they can rely on.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Release Process
+
+> Documentation of a release process that any project maintainer may execute to create a new release version of the software.
+>
+> Multiple people must have permissions to publish releases. A github team must have access to publish packages and package ownership on the associated package repository when possible. For example a Rust project may have multiple owners on crates.io.
+>
+> Core projects must additionally leverage a fully-automated release process, where the only manual step performed by project maintainers is to trigger the process (for example by starting a github workflow or merging an automated pull request).
+>
+> Projects and their releases shouldn't be tied to any single user's machine or keys to ensure continuity of the project. A project isn't an open, community project if only one person can publish releases.
+>
+> Automation makes fewer mistakes than humans, and getting releases right is critical, since only releases are typically used downstream, not random commits from `main`.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Sanitizers and Code Analysis
+
+> Static and dynamic code analysis tools (such as `valgrind` or `miri`) where applicable must be used by core projects.
+>
+> Core projects with non-trivial amounts of unsafe code (e.g. `unsafe` in Rust or any C/C++) must run tests and fuzzers with the relevant sanitizers: Address Sanitizer, Memory Sanitizer, Thread Sanitizer, etc.
+>
+> Automated code analysis is key to meeting our mission of developing runtime environments and language toolchains where security, efficiency, and modularity can all coexist.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Security Process
+
+> All projects must have a documented security process for reporting and disclosing vulnerabilities, managing patches that fix vulnerabilities, and announcing and making available security releases. Furthermore, projects must actually follow their documented processes.
+>
+> Core projects must request Common Vulnerability and Exposure (CVE) numbers for discovered vulnerabilities and report the CVE when disclosing the vulnerability.
+>
+> A tool like [dependabot](https://github.com/dependabot) should be used for security updates only, and not apply all updates indiscriminantly. Updating dependencies should otherwise be done with intention (never automatically). Automatic creation of pull requests is acceptable, but manual review is required to prevent supply chain attacks.
+>
+> Bytecode Alliance projects must be a secure foundation for others to build upon. Transparency and a managed security release process is key to being this foundation.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Semantic Versioning
+
+> All projects must follow either standard semantic versioning or their ecosystem's local-dialect of semantic versioning (for example, Rust and `cargo`'s interpretation of semantic versioning slightly differs from the standard, but is acceptable for Rust Bytecode Alliance projects).
+>
+> A clear versioning scheme is necessary for end-users. We desire consistency across projects and so the Bytecode Alliance has adopted semantic versioning as a required best practice.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Secrets Management
+
+> GitHub organization and repository level secrets should be used. Secrets must not be hard coded in source.
+>
+> For secrets like passwords for the project's associated social media account, these should be stored in the password service paid for by the Bytecode Alliance. Contact the TSC for access and ability to manage a given secret.
+>
+> Secure secret management is a requirement for a secure project. Additionally, projects and their associated accounts shouldn't be tied to any single user's machine or keys to ensure continuity of the project. A project isn't an open, community project if only one person can access its accounts.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Supply Chain Security
+
+> All projects must follow a well-documented process for updating dependencies and auditing them for malicious supply-chain attacks.
+>
+> When applicable, projects should:
+>
+> * Integrate auditing tools in CI (such as `cargo vet`)
+> * Use code review and static analysis tools on dependencies
+>
+> Finally, projects must document and follow their process for responding to upstream vulnerabilities in dependencies.
+>
+> Our mission of developing runtime environments and language toolchains where security, efficiency, and modularity can all coexist necessarily means that we have performed our due dilligence to mitigate software supply chain attacks.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Sustainable Contributor Base
+
+> All projects must have regular contributions from multiple contributors.
+>
+> Core projects must have contributors affiliated with at least two different Bytecode Alliance organizations and the project leadership must have representation from at least two different Bytecode Alliance organizations.
+>
+> There must not be any private information necessary to fully contribute to the project.
+>
+> A project is not considered healthy with only one contributor. An open, community project requires input from multiple stakeholders and does not rely on a single person.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Version Control
+
+> All projects must be hosted on [the Bytecode Alliance Organization](github.com/bytecodealliance) on GitHub.
+>
+> Access controls are managed via the Bytecode Alliance organization on GitHub. This allows for continuity of the project when hosted in one place. Finally, this is the only way to reasonable manage the projects within the organization.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
diff --git a/.github/ISSUE_TEMPLATE/hosted-project.md b/.github/ISSUE_TEMPLATE/hosted-project.md
new file mode 100644
index 0000000..1b162d0
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/hosted-project.md
@@ -0,0 +1,299 @@
+---
+name: "New Hosted Project"
+about: "Propose the creation or adoption of a new hosted project."
+title: "Hosted Project Proposal: The TODO Project"
+labels: "hosted-project-proposal"
+assignees: ""
+---
+
+Proposing the adoption of TODO as a Bytecode Alliance hosted project.
+
+Repository URL: TODO (for existing projects being proposed for adoption)
+
+TODO: One paragraph describing what the project is, what its goals are, and etc...
+
+## Requirements
+
+### Alignment with the Bytecode Alliance Mission
+
+> Projects must have alignment with [the Bytecode Alliance mission:](https://github.com/bytecodealliance/governance/blob/main/mission.md)
+>
+> > Our mission is to provide state-of-the-art foundations to develop runtime environments and language toolchains where security, efficiency, and modularity can all coexist across a wide range of devices and architectures. We enable innovation in compilers, runtimes, and tooling, focusing on fine-grained sandboxing, capabilities-based security, modularity, and standards such as WebAssembly and WASI.
+>
+> The Bytecode Alliance is a group with a specific mission, and we therefore will only sponsor projects that are in alignment with and further that mission. For example, project sponsorship is untenable if the project undermines sandboxing, security, or standardization efforts.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Code Review
+
+#### Description
+
+> All projects must gate merging pull requests on code reviews that audit not only for style but also substance, such as whether security invariants are properly maintained by the new code.
+>
+> It is recommended, but not required, that hosted projects maintain a `CODEOWNERS` file and automatically assign reviewers as well.
+>
+> Code reviews have a demonstrable impact on the quality of source code by catching bugs early, determining the best possible implementation, and fostering trust within the community. Timely responses let contributors know that their work is valued and encourages further contribution.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Code of Conduct
+
+> All Bytecode Alliance projects must:
+>
+> * link to the Bytecode Alliance's Code of Conduct documents from a `CODE_OF_CONDUCT.md` file in root of the repository, and
+> * enforce the codes of conduct among the community and contributors, or escalate to [the Bytecode Alliance CoC Team](mailto:report@bytecodealliance.org), if needed.
+>
+> Having a code of conduct is crucial for creating a positive and respectful environment in any organization, community, or group. It serves as a set of guidelines that outline expected behavior and ethical standards for all members involved.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Continuous Integration Testing
+
+> All projects must run continuous integration (CI) tests on all pull requests and merges. Key project features must be covered by CI.
+>
+> If any part of the CI gates on merging changes that is not reproducible by external contributors, then the project must make affordances to support those external contributors.
+>
+> Implementing CI offers several benefits to software projects, helping ensure correctness and quality, making it an essential practice for modern software development.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Contributor Documentation
+
+> All projects must have a `CONTRIBUTING.md` document in the root of their repository. This document must provide, or link to another form of project-specific documentation that provides, high-quality contributor documentation.
+>
+> See ["How to build a `CONTRIBUTING.md`" by the Mozilla Science Lab](https://mozillascience.github.io/working-open-workshop/contributing/) for more details on what a high-quality `CONTRIBUTING.md` file looks like.
+>
+> A `CONTRIBUTING.md` serves as a guide for potential contributors, outlining the expectations for individuals who wish to contribute to the project. The Bytecode Alliance is a community-driven software foundation and documents like `CONTRIBUTING.md` are necessary for fostering community contributions.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Following the Bytecode Alliance Operational Principles
+
+> All projects must follow [the Bytecode Alliance Operational Principles](https://github.com/bytecodealliance/governance/blob/main/operational-principles.md).
+>
+> In pursuing our mission and vision, the Bytecode Alliance follows a set of operational principles aimed at keeping us aligned on three key aspects: what we want to create, how we want to work together, and how we want to work with others.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Licensing Compatible with the Bytecode Alliance
+
+> All projects must be licensed under the Apache 2.0 license with an LLVM exception. Exemptions may be granted by the board.
+>
+> All projects must only use dependencies and third-party code licensed under one of the following open source licenses:
+>
+> * Apache-2.0 WITH LLVM-exception
+> * Apache-2.0
+> * BSD-2-Clause
+> * BSD-3-Clause
+> * ISC
+> * MIT
+> * MPL-2.0
+> * OpenSSL
+> * Unicode-DFS-2016
+> * Zlib
+>
+> All dependencies and third-party code must be properly attributed.
+>
+> The source for all projects must be available to all members and must be available to all non-members under the same license.
+>
+> All projects must automatically ensure that licensing requirements of dependencies are met in CI.
+>
+> We strive to build an open community and a legally-compatible software ecosystem.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### README
+
+> All hosted projects must have a `README.md` file in the root of the repository which begins with:
+>
+> * The project name and logo (if one exists)
+> * A one-sentence description of the project
+> * `<strong>A <a href="https://bytecodealliance.org/">Bytecode Alliance</a> hosted project</strong>`
+>
+> The most important information about the project should be "above the fold". Projects should identify themselves as Bytecode Alliance projects so that, with time, people associate the Bytecode Alliance with quality projects that they can rely on.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Release Process
+
+> Documentation of a release process that any project maintainer may execute to create a new release version of the software.
+>
+> Multiple people must have permissions to publish releases. A github team must have access to publish packages and package ownership on the associated package repository when possible. For example a Rust project may have multiple owners on crates.io.
+>
+> Projects and their releases shouldn't be tied to any single user's machine or keys to ensure continuity of the project. A project isn't an open, community project if only one person can publish releases.
+>
+> Automation makes fewer mistakes than humans, and getting releases right is critical, since only releases are typically used downstream, not random commits from `main`.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Security Process
+
+> All projects must have a documented security process for reporting and disclosing vulnerabilities, managing patches that fix vulnerabilities, and announcing and making available security releases. Furthermore, projects must actually follow their documented processes.
+>
+> It is recommended that request Common Vulnerability and Exposure (CVE) numbers for discovered vulnerabilities and report the CVE when disclosing the vulnerability.
+>
+> A tool like [dependabot](https://github.com/dependabot) may suffice for hosted projects. Dependabot should be used for security updates only, and not apply all updates indiscriminantly. Updating dependencies should otherwise be done with intention (never automatically). Automatic creation of pull requests is acceptable, but manual review is required to prevent supply chain attacks.
+>
+> Bytecode Alliance projects must be a secure foundation for others to build upon. Transparency and a managed security release process is key to being this foundation.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Semantic Versioning
+
+> All projects must follow either standard semantic versioning or their ecosystem's local-dialect of semantic versioning (for example, Rust and `cargo`'s interpretation of semantic versioning slightly differs from the standard, but is acceptable for Rust Bytecode Alliance projects).
+>
+> A clear versioning scheme is necessary for end-users. We desire consistency across projects and so the Bytecode Alliance has adopted semantic versioning as a required best practice.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Secrets Management
+
+> GitHub organization and repository level secrets should be used. Secrets must not be hard coded in source.
+>
+> For secrets like passwords for the project's associated social media account, these should be stored in the password service paid for by the Bytecode Alliance. Contact the TSC for access and ability to manage a given secret.
+>
+> Secure secret management is a requirement for a secure project. Additionally, projects and their associated accounts shouldn't be tied to any single user's machine or keys to ensure continuity of the project. A project isn't an open, community project if only one person can access its accounts.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Supply Chain Security
+
+> All projects must follow a well-documented process for updating dependencies and auditing them for malicious supply-chain attacks.
+>
+> When applicable, projects should:
+>
+> * Integrate auditing tools in CI (such as `cargo vet`)
+> * Use code review and static analysis tools on dependencies
+>
+> Finally, projects must document and follow their process for responding to upstream vulnerabilities in dependencies.
+>
+> Our mission of developing runtime environments and language toolchains where security, efficiency, and modularity can all coexist necessarily means that we have performed our due dilligence to mitigate software supply chain attacks.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Sustainable Contributor Base
+
+> All projects must have regular contributions from multiple contributors.
+>
+> It is recommended that hosted projects additionally have contributors affiliated with at least two different Bytecode Alliance organizations and that the project's leadership has representation from at least two different Bytecode Alliance organizations.
+>
+> There must not be any private information necessary to fully contribute to the project.
+>
+> A project is not considered healthy with only one contributor. An open, community project requires input from multiple stakeholders and does not rely on a single person.
+>
+> The TSC may waive the above contributor base requirements under certain conditions. In particular, the TSC may decide to adopt crucial upstream dependencies of existing Bytecode Alliance projects that are otherwise effectively unmaintained or only have a single maintainer.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Version Control
+
+> All projects must be hosted on [the Bytecode Alliance Organization](github.com/bytecodealliance) on GitHub.
+>
+> Access controls are managed via the Bytecode Alliance organization on GitHub. This allows for continuity of the project when hosted in one place. Finally, this is the only way to reasonable manage the projects within the organization.
+
+TODO: argument that this requirement is fulfilled and supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+## Recommendations
+
+### Changelog
+
+> It is recommended that hosted projects highlight key additions, breaking changes, security fixes, and otherwise noteworthy changes in a changelog.
+>
+> See [keepachangelog.com](https://keepachangelog.com/en/1.1.0/) for a recommended approach.
+>
+> We are building an ecosystem that developers can depend on, and one small part of that is communicating important changes downstream.
+
+TODO: discussion of this recommendation and any supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Continuous Fuzzing
+
+> Not all projects will necessarily benefit from fuzzing, for example benchmark suites. The TSC may choose lift this requirement for a particular project.
+>
+> It is recommended that hosted projects have 24/7, round the clock, continuous fuzzing. The fuzzing should exercise significant amounts of the code base and test the project's most important properties, such as sandboxing. Bugs and vulnerabilities discovered via fuzzing should be addressed promptly.
+>
+> Part of our open-source and open contribution model, the corpus and setup for running fuzzing should be open-sourced as part of the project.
+>
+> Faults discovered via fuzzing must be reported privately to the project's core team so that the project's security vulnerability process can be followed properly, if necessary. For example, fuzzing infrastructure must not automatically open public issues for any fault that is discovered.
+>
+> Continuous fuzzing is a valuable practice for projects, due to its significant benefits in improving security and reliability. Within the Bytecode Alliance, we host projects that provide a sandbox. The fidelity of these sandboxes must be battle-tested via a number of methodologies including automated fuzzing.
+
+TODO: discussion of this recommendation and any supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### End-User Documentation
+
+> We abide by [the OpenSSF requirements for documentation](https://bestpractices.coreinfrastructure.org/en):
+>
+> > The documentation of an external interface explains to an end-user or developer how to use it. This would include its application program interface (API) if the software has one. If it is a library, document the major classes/types and methods/functions that can be called. If it is a web application, define its URL interface (often its REST interface). If it is a command-line interface, document the parameters and options it supports. In many cases it's best if most of this documentation is automatically generated, so that this documentation stays synchronized with the software as it changes, but this isn't required. The project MAY use hypertext links to non-project material as documentation. Documentation MAY be automatically generated (where practical this is often the best way to do so).
+>
+> Furthermore, we identify a few different types of (sometimes overlapping) documentation:
+>
+> * **API documentation**: Documentation for each type, method, function, and module in a library.
+> * **Architectural overviews**: High-level documentation about the architecture of the project and how it works from a 1000-foot view that helps endusers take advantage of the project in the best way possible and helps onboard new contributors.
+> * **Examples**: Code examples that show off how to use the project as a whole or particular features it supports.
+> * **Guides and tutorials**: Long-form prose, with code samples interspersed, that shows how to accomplish a task using the project.
+>
+> API and CLI flag documentation is required for hosted projects; all other types are recommended.
+>
+> Documentation is necessary for end-users to productively use the project; source code comments are not sufficient.
+
+TODO: discussion of this recommendation and any supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Issue Triage Process
+
+> Hosted projects must use an issue tracker for tracking individual issues.
+>
+> It is recommended that hosted projects should additionally have a documented process for expeditiously triaging incoming issues and pull requests, and follow that process. Contributors should get prompt responses to their issues and pull requests, even if a response is not an immediate fix or review.
+>
+> For a successful community-driven project, expedient communication within issues and PRs encourages further collaboration and contribution.
+
+TODO: discussion of this recommendation and any supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Leverage the Bytecode Alliance RFC Process
+
+> A request for comments (RFC) is a technique for soliciting the community and contributors for feedback on proposed major changes and decisions.
+>
+> It is recommended that hosted projects follow [the Bytecode Alliance RFC process](https://github.com/bytecodealliance/rfcs/blob/main/accepted/rfc-process.md) for changes that significantly affect project stakeholders or contributors. The RFCs repo describes [when an RFC is needed](https://github.com/bytecodealliance/rfcs/#when-is-an-rfc-needed) in more detail:
+>
+> > Many changes to Bytecode Alliance projects can and should happen through every-day GitHub processes: issues and pull requests. An RFC is warranted when:
+> >
+> > * The work involves changes that will significantly affect stakeholders or project contributors. Each project may provide more specific guidance. Examples include:
+> >     * Major architectural changes
+> >     * Major new features
+> >     * Simple changes that have significant downstream impact
+> >     * Changes that could affect guarantees or level of support, e.g. removing support for a target platform
+> >     * Changes that could affect mission alignment, e.g. by changing properties of the security model
+> > * The work is substantial and you want to get early feedback on your approach.
+>
+> This is a best practice for aligning contributors, the community, and downstream projects' needs with proposed technical implementations.
+
+TODO: discussion of this recommendation and any supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Production Use
+
+> It is recommended that hosted projects have demonstrated use in production by at least three independent organizations which are, in the TSC's judgement, of adequate quality and scope.
+>
+> It is recommended that projects track production usage by organizations in an `ADOPTERS.md` at the root of the project, for example see [`ADOPTERS.md`](https://github.com/bytecodealliance/wasmtime/blob/main/ADOPTERS.md) in Wasmtime.
+>
+> Projects should demonstrate that they are practical, useful, and reliable enough to use in production.
+
+TODO: discussion of this recommendation and any supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Public Project Meetings and Notes
+
+> It is recommended that hosted projects hold regular and public project meetings. Meeting times and frequency should be advertised publicly, for example in the project's `CONTRIBUTING.md`. To avoid spam and "Zoom bombing", the video conferencing link need not be public, but should be available upon request.
+>
+> Agendas for upcoming meetings and notes from past meetings should be published publicly. The notes should be in the `bytecodealliance/meetings` repository.
+>
+> Public meetings encourage open communication, collaboration, and engagement within the project's community. Notes allow community members who were not present to remain aligned and can document any decisions made during the meeting.
+
+TODO: discussion of this recommendation and any supporting evidence (such as links to code, documentation, issues, and pull requests)
+
+### Sanitizers and Code Analysis
+
+> Static and dynamic code analysis tools (such as `valgrind` or `miri`) where applicable are recommended to be used by hosted projects.
+>
+> It is recommended that hosted projects with non-trivial amounts of unsafe code (e.g. `unsafe` in Rust or any C/C++)  run tests and fuzzers with the relevant sanitizers: Address Sanitizer, Memory Sanitizer, Thread Sanitizer, etc.
+>
+> Automated code analysis is key to meeting our mission of developing runtime environments and language toolchains where security, efficiency, and modularity can all coexist.
+
+TODO: discussion of this recommendation and any supporting evidence (such as links to code, documentation, issues, and pull requests)
diff --git a/TSC/core-and-hosted-projects.md b/TSC/core-and-hosted-projects.md
new file mode 100644
index 0000000..57d914b
--- /dev/null
+++ b/TSC/core-and-hosted-projects.md
@@ -0,0 +1,56 @@
+# Bytecode Alliance Core and Hosted Project Requirements
+
+This document defines the process for applying for adoption as a hosted project or promotion from hosted project to core project.
+
+## What are Hosted and Core Projects?
+
+The Bytecode Alliance holds itself and its projects, whether hosted or core, to exceptional standards. This is part of our principle of [curation](https://github.com/bytecodealliance/governance/blob/main/operational-principles.md?plain=1#L17-L23) and we do not believe we can accomplish our [mission](https://github.com/bytecodealliance/governance/blob/main/mission.md) otherwise.
+
+Core projects are the Bytecode Alliance's flagships and are held to an even higher standard than hosted projects. In return, core projects are prominently advertised on the Bytecode Alliance webpage and can elect a delegate to the Bytecode Alliance's Technical Steering Committee, as per [the TSC charter](https://github.com/bytecodealliance/governance/blob/main/TSC/charter.md#composition).
+
+Note that it is expected that most hosted projects will not become core projects, even if they satisfy the [technical requirements of core projects](../.github/ISSUE_TEMPLATE/core-project.md). Core project status is reserved for projects of exceptional strategic value to the Bytecode Alliance in the fulfillment of its mission. These projects typically have the following qualities:
+
+* End-user facing and widely adopted
+* Under active development and have long-term roadmaps
+* Major-versioned releases
+
+Core projects must further the mission of the Bytecode Alliance and be seen as vital to its success, as assessed by the TSC.
+
+## Applying for Adoption as a Hosted Project
+
+If you would like to propose that the Bytecode Alliance adopt your project as a new hosted project, you may perform the following steps:
+
+* [ ] File an issue against [the Bytecode Alliance governance repository](https://github.com/bytecodealliance/governance) using [the "New Hosted Project" issue template](https://github.com/bytecodealliance/governance/issues/new/choose).
+  * Fill in all of the `TODO`s.
+  * Do not make unsubstantiated claims; provide evidence. For example, if you claim that your project performs code review, provide a handful of links to pull request reviews that demonstrate this.
+
+The Bytecode Alliance Technical Steering Committee (TSC) will then perform the following steps:
+
+* [ ] Provide timely acknowledgment of the application.
+* [ ] Perform an in-depth review of the project, evaluate whether it meets the hosted project requirements, and decide based on consensus whether to accept the project.
+* [ ] Reply in the issue with the results of the review, providing any feedback they might have, and whether the project has been accepted.
+* [ ] If it has been accepted, then the TSC will work with maintainers on the logistics of moving the repository to the `bytecodealliance` github organization.
+
+## Applying for Promotion from Hosted Project to Core Project
+
+Once the project maintainers have come to a consensus agreement that they wish for their project's promotion to a core project, they may initiate the application process by performing the following steps:
+
+* [ ] Create an issue within the [the Bytecode Alliance governance repository](https://github.com/bytecodealliance/governance) using [the "New Core Project" issue template](https://github.com/bytecodealliance/governance/issues/new/choose).
+  * Fill in all of the `TODO`s.
+  * Do not make unsubstantiated claims; provide evidence. For example, if you claim that your project has a CI job running tests under [AddressSanitizer](https://clang.llvm.org/docs/AddressSanitizer.html), provide links to its CI configuration, test infrastructure, and bugs caught.
+
+The Bytecode Alliance Technical Steering Committee (TSC) will then perform the following steps:
+
+* [ ] Provide timely acknowledgment of the application.
+* [ ] Perform an in-depth review of the project:
+  * The TSC will consider the strategic value of the project to the Bytecode Alliance, how it furthers the Bytecode Alliance's mission, as well as its value and influence in the broader community.
+  * The TSC will evaluate whether it meets the technical requirements for core projects.
+  * Finally, the TSC will decide based on consensus whether to promote the project.
+* [ ] Reply in the issue with the results of the review, providing any feedback they might have, and whether the project has been promoted.
+* [ ] If it has been promoted, then the project maintainers will [choose a delegate to represent the project on the TSC](https://github.com/bytecodealliance/governance/blob/d0310b2f4fab7d5bd076627b196dfc0ffe040ec1/TSC/charter.md#composition).
+
+## Handling of Existing Projects
+
+At the point of adoption of these requirements, all existing projects are implicitly treated as Hosted Projects. The TSC will over time work with project maintainers to ensure that they satisfy the requirements for Hosted Projects, and explicitly add their projects to the list of Hosted Projects.
+
+Additionally, we encourage maintainers of existing projects to consider applying for Core Project status, if they believe their project is a good fit, of exceptional strategic Bytecode Alliance value, and in compliance with the stricter requirements.
diff --git a/templates/projects/proposal.md b/templates/projects/proposal.md
deleted file mode 100644
index 7582d0d..0000000
--- a/templates/projects/proposal.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# Proposal to Create $PROJECT_NAME
-
-This document is a proposal to create $PROJECT_NAME as a formal (Core|Hosted) Project under the auspices of the TSC of the Bytecode Alliance, as specified in the [TSC Charter].
-
-## Project Summary
-
-_Describe the project and its goals. Target 1-2 paragraphs._
-
-### Existing Resources
-
-- [GitHub repository](https://github.com/YOUR_PROJECT)
-- [Documentation](https://example.com/)
-- [Governance Document](https://example/GOVERNING_DOCUMENT)
-- [Homepage](https://example.com/)
-- [Twitter](https://twitter.com/YOUR_PROJECT)
-- _include other relevant links here_
-
-## Governance Summary
-
-_1-3 paragraphs summarizing how project governance will be organized._
-
-_Note: No process can give one organization an elevated position. See the [TSC Charter]_
-
-_Note: If you opted for Core Project status, you must explain how this project will adhere to the strict alignment and process requirements of Core Projects._
-
-## Software Development Process
-
-_1-3 paragraphs explaining how the project uses pull requests, issue maintenance, LGTM policy, release management, and security processes. Emphasize how code quality is ensured._
-
-## Alignment with Bytecode Alliance Mission and Goals
-
-Bytecode Alliance projects represent the mission and goals of the Bytecode Alliance itself.
-We understand that as a Bytecode Alliance project, our project must adhere to the [TSC Charter] and other governing documents (such as the [Security Policies] and [IP Policy]).
-As a Bytecode Alliance project, our project's source code and other pieces of intellectual property will be assigned to the Bytecode Alliance.
-
-We understand and agree that:
-
-- All code for this project must be under the [Apache v2 License with the LLVM exception](/PROJECT_LICENSE), unless an exception is required for compliance with existing licensing, and granted by the Bytecode Alliance's board of directors per [IP Policy] §4. If our code is not already licenses accordingly, we will take the necessary steps to correct this prior to becoming a Bytecode Alliance Project.
-- We will comply with the [Security Policies].
-- Project name, trademarks, logos, wordmarks, and other intellectual property other than source code and documentation copyright is assigned to Bytecode Alliance per the [IP Policy].
-- Social media handles, GitHub repository access, and other relevant communication and coordination platforms will be overseen by Bytecode Alliance. Administrative/Owner permissions will be granted to the Bytecode Alliance for all such accounts.
-- We will abide by the definition of a project as set forth in the [TSC Charter].
-- This project must remain under active development or maintenance, or it may be archived by the Bytecode Alliance.
-- This project may be reviewed from time to time by the TSC, and project maintainers will assist with this review process.
-- Project members will be able to participate in Bytecode Alliance governance, as specified in the [TSC Charter] and other governing documents.
-
-### Petition for Core Project Status
-
-_If this project is requesting Core Project status, add 1-3 paragraphs explaining how this project aligns with the Bytecode Alliance definition of a core project, and the Bytecode Alliance core values. If this project is applying for Hosted Project status, this entire section (including the heading) can be deleted_
-
-## Supporting Members 
-
-The following individuals support the creation of $PROJECT_NAME:
-
-- Full Name (Organization)
-
-[Security Policies]: https://bytecodealliance.org/security
-[TSC Charter]: https://github.com/bytecodealliance/governance/blob/main/TSC/charter.md
-[IP Policy]: https://bytecodealliance.org/assets/ip-policy.pdf
\ No newline at end of file