We can see the ID, L73021 AM, and the instance information. It's shown as a JSON document, and you can see that the structure mirrors that in the LetterOfCredit definition, but it has real instance data in it.

You can see that every asset and participant contained within the letter has a class ($class), which is formed from the namespace concatenated with the type name. For example:

"$class": "org.example.loc.LetterOfCredit"
"$class": "org.example.loc.ProductDetails"

Notice also how the information for this letter has been captured:

"letterId": "L73021 AM"
"productType": "Computer"
"quantity": "1250"

Finally, notice how the letter is in its final state:

"status": "CLOSED"
"closeReason": "Letter has been completed."

All of this data is incredibly powerful. Why? Because the type and instance information is kept together, just like in a real contract, it can be properly interpreted after it's been written. You can imagine how helpful that is for analytics tools who like to look for patterns in the data!

For reference attributes, we can see that the structure is a little different:

"applicant": "resource:org.example.loc.Customer#alice"
"beneficiary": "resource:org.example.loc.Customer#bob"
"issuingBank": "resource:org.example.loc.Bank#BOD"
"exportingBank": "resource:org.example.loc.Bank#ED"

We can see that these attributes are references to participants, and if we click on the Participant tab, we're able to see them! Click on the Bank tab: