For data which is modelled bi-temporally, the asAt is the timestamp when the data was actually saved into the system.
asAts are determined internally by LUSID and cannot be updated by the user. As such, methods which update data in LUSID do not take an asAt parameter.
All query APIs include a parameter for specifying the asAt timestamp. This allows data to be extracted from LUSID as it was at a point in the past, regardless of any subsequent updates or corrections.
A more concrete example would be how the system will deal with a correction. We can, in effect deal with 2 updates for the same business time (effectiveAt) and know that they happened on 2 different asAt times. This means we can ask for the state of that entity either before or after the second update/correction.
This enables us to build a system which can always reproduce its state at any point in time. You can, simply put, ask for how the entire system looked asAt 5pm yesterday and be guaranteed to get the correct answer. Anything that happened after 5pm would have an asAt later than 5pm.