diff --git a/specification/docs/implementation-solidity.md b/specification/docs/implementation-solidity.md
index 68a1600..6d889ea 100644
--- a/specification/docs/implementation-solidity.md
+++ b/specification/docs/implementation-solidity.md
@@ -21,3 +21,7 @@ Each of the core contracts must first be deployed. Then the DAO contract is depl
 
 ### Bench
 
+## Other
+
+- `getPostAuthors`
+- `propagateReputation`
diff --git a/specification/docs/system-design.md b/specification/docs/system-design.md
index bcd2bcf..b87aad6 100644
--- a/specification/docs/system-design.md
+++ b/specification/docs/system-design.md
@@ -97,19 +97,11 @@ To achieve the Bench requirements, the contract must do the following:
 
 **`totalSupply`** refers to the total amount of REP held by all DAO members.
 
-**`ValdiationPoolResult`** Fields
-
-| Name | Type | 
-| --- | --- | 
-| `sender` | wallet address |
-| `votePasses` | boolean |
-| `quorumMet` | boolean |
-
 **`InitiateValidationPool`** Parameters
 
 | Name | Type | 
 | --- | --- | 
-| `postId` | string identifying the Target Post|
+| `postId` | string identifying the Target Post |
 | `duration` | positive integer number of seconds |
 | `quorum` | integer numerator, integer denominator |
 | `winRatio` | integer numerator, integer denominator |
@@ -118,9 +110,13 @@ To achieve the Bench requirements, the contract must do the following:
 | `callbackOnValidate` | function(`ValidationPoolResult`, `callbackData`) | Optional callback to be executed when the VP is concluded |
 | `callbackData` | bytes | Opaque data to be passed back to `callbackOnValidate` |
 
-    
-
+**`ValdiationPoolResult`** Fields
 
+| Name | Type | 
+| --- | --- | 
+| `sender` | wallet address |
+| `votePasses` | boolean |
+| `quorumMet` | boolean |
 
 
 ### Forum
@@ -135,6 +131,55 @@ To achieve the Forum requirements, the contract must do the following:
 
     1. This method must be called only by the Bench, when a Validation Pool is accepted.
 
+**`AddPost`** Parameters
+
+| Name | Type |
+| --- | --- |
+| `postId` | string |
+| `authors` | Array<`AuthorWeight`> |
+| `references` | Array<`ReferenceWeight`> |
+
+**`AuthorWeight`** is an object or tuple with the following fields:
+
+| Name | Type |
+| --- | --- |
+| `authorAddress` | wallet address |
+| `weightPPM` | integer |
+
+**`ReferenceWeight`** is an object or tuple with the following fields:
+
+| Name | Type |
+| --- | --- |
+| `targetPostId` | string |
+| `weightPPM` | integer |
+
+**`PropagateReputation`** Parameters
+
+| Name | Type |
+| --- | --- |
+| `postId` | string |
+| `amount` | integer |
+| `initialNegative` | boolean |
+| `depth` | integer |
+
+Logic for **`PropagateReputation`**
+
+1. `PropagateReputation` is a recursive function.
+
+1. The recursion is initiated by a Validation Pool targeting a given Post.
+
+1. Each time `PropagateReputation` is called, `depth` should be incremented.
+
+1. Negative references "leach" reputation from the target, while positive references "donate" reputation. A Post may include both negative and positive references. Negative references should be processed first, so that a Post may then donate the leached reputation.
+
+1. There are cases where reputation effects are unable to be propagated, due to the following constraints:
+    1. Post and Author reputations may not drop below zero.
+    1. A negative reference may at most undo the effects of prior posts, but not reverse them.
+    1. `depth` may not exceed `depthLimit` (a.k.a. Reference Chain Limit).
+
+    `PropagateReputation` should therefore return the amount that was unable to be propagated. We refer to this as a "refund". Subtracting this refund amount from the attempted amount gives the actual amount propagated.
+
+
 ### Proposal
 
 To achieve the Proposals requirements, the contract must do the following: