diff --git a/docs/fcas/index.rst b/docs/fcas/index.rst
index 4f050a4..827d7fc 100644
--- a/docs/fcas/index.rst
+++ b/docs/fcas/index.rst
@@ -101,4 +101,5 @@ Index
     solution_datanote
     solution_dataeplt
     solution_examples
+    solution_probntec
     solution_techtool
diff --git a/docs/fcas/solution_probntec.rst b/docs/fcas/solution_probntec.rst
new file mode 100644
index 0000000..d63ff94
--- /dev/null
+++ b/docs/fcas/solution_probntec.rst
@@ -0,0 +1,57 @@
+.. _solution_probntec.rst:
+
+Conundrum of Tracking of Non-Technical Contributions
+====
+
+As contributions that involve interacting with services are the only ones that
+publish a message on the 
+`Fedora Messaging <https://fedora-messaging.readthedocs.io/>`_ bus, they are
+the only ones that get tracked. These services predominantly facilitate for
+technical contributions alone and hence, it becomes increasingly difficult to
+track non-technical contributions. Owing to the wide range of creating non
+technical contributions and a similarly huge number of subjective methods to
+keep track of those - it is comparatively difficult to come up with an
+objective method of describing them. What might look like a contribution to one
+might not look like a contribution to someone else and therefore, the service
+would not be able to reliably track non-technical contributions.
+
+One of the workarounds that could help solving this problem is by creating 
+badges on the 
+`Fedora Badges <https://fedora-arc.readthedocs.io/en/latest/badges/index.html>`_
+platform for each type of non-technical contribution. This cannot be a
+solution as this method scales incredibly poorly as the members go on adding
+new badges of the manually-awarded kind for tracking each type of non-technical
+contributions. This could potentially lead to situations where there are
+thousands of badges pertaining to a type of non-technical contribution but with
+handful of awardees per badge. Going against the norm of having "subject" 
+usernames as owners of contribution activities, using Fedora Badges to track
+contributions would lead to treating both "subject" usernames (cause of the
+message publication event) and "object" usernames (involved in the said
+contribution activity) to own a contribution activity.
+
+How? Assuming a contribution event where a "Member X" (who has the access to
+award a certain "Badge A" to members who do "Task B") awards a "Badge A" to
+"Member Y". As this was a non-technical contribution and because this could not
+be automatically tracked by the Fedora Badges' Message Consumer entity - the 
+event of "Member Y" performing "Task B" could not be reliably and automatically
+tracked. The event of awarding the badge essentially confirms two contribution
+activities - the first one being "Member Y" performing "Task B" and the second
+one being "Member X" awarding the "Member Y" with "Badge A". In the first 
+contribution activity, the "Member Y" owns the contribution but they are 
+dependent on "Member X" to award them the badge to have their contribution 
+tracked. The activity of awarding the badge itself is a contribution so in the
+second activity, the "Member X" owns the contribution. 
+
+This should be used as an absolute "last ditch effort" to track non-technical
+contributions of the kind that do not automatically publish a message on the
+Fedora Messaging bus when they take place. As the badges cannot be tightly
+associated with the contribution activity itself and the fact that the way of
+tracking those are manual in nature, they are very susceptible to be left 
+untracked (due to reasons like the "contribution owner" forgetting to claim 
+a badge when they made the "contribution activity" or the "badge felicitator"
+being unavailable when being reached out causing delays in tracking of the 
+said activity) or to be tracked unfairly (due to reasons like the "badge 
+felicitator" awarding a certain badge to their friends who might not have done
+the said "contribution activity" or random members claiming the badge from the
+associated link in bad faith). In the larger scheme of things - this will end
+greatly skewing the contributor statistics for the worse.