diff --git a/proposals/techical-alignment/README.adoc b/proposals/techical-alignment/README.adoc
new file mode 100644
index 00000000..5fada2c0
--- /dev/null
+++ b/proposals/techical-alignment/README.adoc
@@ -0,0 +1,25 @@
+# MicroProfile and Jakarta EE Technical Alignment
+
+MicroProfile was founded in 2016 as a compliment to Java EE, aimed at "driving innovation for future standardization" around microservices. Free from backwards compatibility, the vision was to provide a place where vendors and users combined can experiment, make mistakes, learn together, reinvent and reach stablization much faster.
+
+The initial vision was proven APIs would be standardized via the JCP process.  In August 2017 the Eclipse MicroProfile community submitted MicroProfile Config to the JCP as link:https://jcp.org/en/jsr/detail?id=382[JSR-382].  Quotes around the time reinforced the vision and anticipated relationship to the JCP.
+
+ - _"How we are collaborating in Open Source around this: Build a strong community; Collaborate on specifications; Encourage multiple implementations; Standardize technologies when ready"_ - John Clingan, 2019-07-07, link:https://developers.redhat.com/blog/2017/07/07/microprofile-optimizing-enterprise-java-for-a-microservices-architecture/[MicroProfile: Optimizing Enterprise Java for a Microservices Architecture]
+ - _"ideas that are rapidly prototyped in MP can quickly become standards via the JCP process and gain a larger audience"_, - Martijn Verburg, 2017-09-27, link:https://blog.payara.fish/microprofile-panel-one-year-on[MicroProfile One Year On]
+ - _"It was in our mission statement from the beginning that we would never subvert or undermine the JCP, but participate in it to accelerate innovation and standardization. By submitting this JSR, we are fulfilling that aspect of our mission statement."_ - David Blevins, 2017-08-23, link:https://adtmag.com/articles/2017/08/23/eclipse-microprofile.aspx[Eclipse MicroProfile 1.1 Paving a New Path for Java EE]
+ - _"The Configuration API JSR is based on innovation in the Eclipse MicroProfile Config project carried out by several contributors both corporate and individual ... with the hope of future standardization via the JCP."_ - Kevin Sutter, 2017-09-12, link:https://jcp.org/en/jsr/detail?id=382[JSR 382 Configuration API 1.0]
+
+After the move of Java EE to Eclipse as Jakarta EE, similar thoughts were expressed.
+
+- _"Since both MicroProfile and Jakarta EE are managed by Eclipse Foundation, the specifications defined under MicroProfile (e.g. MicroProfile Fault Tolerance) could be submitted to Jakarta EE and eventually standardized."_ - Emily Jiang, 2018-09-03, https://jaxenter.com/understanding-jakarta-ee-series-ibm-148922.html[Understanding Jakarta EE: “We can treat MicroProfile as a sports car and Jakarta EE as a minibus”]
+
+The underlying consensus being that MicroProfile innovations are not standards.  Users who use MicroProfile and vendors who implement it must understand the goal is not stability, but innovation.  Breaking changes will occur.  Innovation is prioritized over stability.
+
+# Proposals for Standardization
+
+After Jakarta EE 9 ships Jakarta specifications, which are standards, will want to benefit from the innovations of MicroProfile.  The critical question is what is the 2020 answer for how a MicroProfile specification becomes a standard.
+
+Proposals in discussion:
+
+ - link:proposal-microprofile-becomes-standards-initiative.adoc[MicroProfile becomes a standards initiative]
+ - link:proposal-specifications-graduation-to-jakarta.adoc[Innovations graduate to Jakarta]
diff --git a/proposals/techical-alignment/proposal-microprofile-becomes-standards-initiative.adoc b/proposals/techical-alignment/proposal-microprofile-becomes-standards-initiative.adoc
new file mode 100644
index 00000000..dd115c66
--- /dev/null
+++ b/proposals/techical-alignment/proposal-microprofile-becomes-standards-initiative.adoc
@@ -0,0 +1,33 @@
+# MicroProfile Becomes A Standards Initiative
+
+Under this proposal the concept of stable or "standard" specifications is introduced in order to keep APIs in the MicroProfile java package once they are deemed stable.
+
+ - API classes remain in `org.eclipse.microprofile`
+ - Once a specification is stable or "standard" it cannot be changed in a backwards-incompatible way
+ - some clear label or marker would need to be created to distinquish "standard" specifications
+ - Only specifications that are marked "stable" or "standard" can be used in a Jakarta EE specification
+ 
+When phrases like "innovation over stability" or "breaking changes are ok" are spoken, all community members must understand it does not apply to stable APIs.
+
+# Long-term Effects
+
+Under this proposal MicroProfile will become a predominately stable community.
+
+ - Scenario 1: If a specification on average becomes stable in 2 years, with 8 new specifications added evenly over the next 4 years we would still be roughly 75% stable (16 total, 12 stable).  From there 8 specifications added evenly over the subsequent 4 years we would be roughtly 83% stable and fairly large at 24 specifications.  Under this scenario MicroProfile risks becoming bloated and not "micro" anymore.
+ 
+ - Scenario 2: If a specification on average becomes stable in 2 years, with 1 new specifications added evenly over the next 4 years we would still be roughly 83% stable (12 total, 10 stable).  From there 4 specifications added evenly over the subsequent 4 years we would be roughtly 88% stable.
+
+# Open Questions
+
+ * If a stable specification depends on a non-stable spec, how does that work?
+ * If MicroProfile needs to make a blanket breaking change (such as the recent pom discussion), how does that work?
+ * With both MicroProfile and Jakarta EE being focused on creating stable standards, the relationship between MicroProfile and Jakarta EE will become less clear.
+ ** If you have a new idea where do you submit it?
+ ** If if all unproven ideas are submitted in MicroProfile and never leave, how does Jakarta grow?
+ ** Will the intended synergy between the two become lost and eventually be two brands for the same inseparable thing?
+ * Does this create a circular dependency that could be difficult to manage?
+ * Could users find it difficult to understand which APIs are stable and when?
+ ** "I see Metrics is stable, but I upgraded and my app broke.", "You're using Metrics 2.0.  It didn't become stable till 3.0."
+ ** "In what version of MicroProfile did healthcheck become stable?  Was it MP 4.0 or 5.0?", "I don't remember it's been 10 years."
+ * How does MicroProfile attract an audience promising both stability and instability/innovation?
+ * Will consensus become increasingly difficult as the focus of the committer base diverges into two camps; those who favor innovation over stability and those who favor stability over innovation.
diff --git a/proposals/techical-alignment/proposal-specifications-graduation-to-jakarta.adoc b/proposals/techical-alignment/proposal-specifications-graduation-to-jakarta.adoc
new file mode 100644
index 00000000..78e8c971
--- /dev/null
+++ b/proposals/techical-alignment/proposal-specifications-graduation-to-jakarta.adoc
@@ -0,0 +1,26 @@
+# Innovations Graduate to Jakarta
+
+Under this proposal specifications ready for standardization are proposed as Jakarta specifications via Creation Review defined by the Jakarta EE Specification Process (JESP).
+
+ - API is repackaged into the `jakarta` namespace as currently defined by the Jakarta EE Specification Committee
+ - Vendors may ship and support the prexisting `org.eclipse.microprofile` package to provide optional compatibility
+ - Once a MicroProfile innovation is submitted and accepted (passes creation review), its Github repository is frozen
+
+Pros:
+
+ - Consumers will have a clear rule to follow that stands the test of time
+ - Greater clarity in community goals helps consumers better understand Jakarta EE / MicroProfile relationship and synnergy
+ - Maximum ability to attract intended audience of those willing to try cutting edge apis and do not necessarily care about standards
+ - Less community conflict arising from those pursuing stability and those pursuing experimentation
+
+Cons:
+
+ - MicroProfile will see change associated with adapting to package renames
+ 
+# Long-term Effects
+
+Number of projects could become very low at times.
+
+# Open Questions
+
+ - When do we cut over to the `jakarta` version of the specification?