docs: random updates

website/docs/how-does-it-work/issuance-status.md

@@ -47,7 +47,7 @@ An OpenAttestation verifier:
   1. Gets back the document store contract address from the document itself.
   1. Ensures that the `targetHash` and the `proof` matches the `merkleRoot`.
   1. Checks the `merkleRoot` is in the document store provided, by calling the `isIssued` function from the deployed contract.
-- Checks the `merkleRoot` of the document has been issued:
+- Checks the `merkleRoot` of the document hasn't been revoked:
   1. Gets back the document store contract address from the document itself.
   1. Checks the `targetHash` is **not** in the document store provided, by calling the `isRevoked` function from the deployed contract.
   1. Checks the `merkleRoot` is **not** in the document store provided, by calling the `isRevoked` function from the deployed contract.
@@ -60,7 +60,7 @@ At the moment, OpenAttestation only supports one DID method: `ethr`.
 
 ### Issuance
 
-DIDs [are significantly faster and incur not costs](/docs/verifiable-document/comparison). They could directly use the `targetHash` of the document (which is unique) and sign it using the private key associated. However for consistency with our initial design, we sign the `merkleRoot`.
+DIDs [are significantly faster and incur no costs](/docs/verifiable-document/comparison). They could directly use the `targetHash` of the document (which is unique) and sign it using the private key associated. However for consistency with our initial design, we sign the `merkleRoot`.
 
 The information about the signature are added to the document, into the `proof` property. That's it, the document has been issued.
 

website/docs/transferable-record/issuing-transferable-record.md

@@ -25,9 +25,11 @@ open-attestation token-registry issue -a 0x8431012Bc040942B59e3C5bf428221eab0b2f
 
 Note to replace the following values:
 
-- `0x8431012Bc040942B59e3C5bf428221eab0b2f723` with your token registry contract address
-- `0x0d9839a8034cb783d98bd57bcbaafb4dc3614c4193d2edf8a655c1ec6635b7ea` with your merkle root (with a `0x` prefix)
-- `0xec733A8322f8216eaf8e5566e750bfee3974B7f3` with your title escrow contract address
+|Argument |Description                            |Example Value                                                       |
+|---------|---------------------------------------|--------------------------------------------------------------------|
+|-a       |Address of your token registry contract|`0x8431012Bc040942B59e3C5bf428221eab0b2f723`                        |
+|--tokenId|Merkle root hash (with a `0x` prefix)  |`0x0d9839a8034cb783d98bd57bcbaafb4dc3614c4193d2edf8a655c1ec6635b7ea`|
+|--to     |Address of your title escrow contract  |`0xec733A8322f8216eaf8e5566e750bfee3974B7f3`                        |
 
 Once the document has been issued, you will be able to see an output similar to the following:
 

website/docs/transferable-record/preparing-transferable-record.md

@@ -62,6 +62,8 @@ Remember to replace the `tokenRegistry` value with your token registry smart con
 Notice the difference between a transferable record and a verifiable document is the use of `tokenRegistry` instead of `documentStore` in declaring the smart contract address.
 
 > For transferable record, you may not batch process it with other documents. Your directory `raw-documents` may only contain one file.
+> 
+> Otherwise, the one-to-one mapping between a token ID and the asset ownership record will be violated as batching the records will result in a one-to-many mapping.
 
 ## Wrapping Transferable Document