Can @future Methods Access Updated Record Data After a Trigger Commit?

Goal

The goal is to determine whether an @future method can see changes made to a record in the transaction that invoked it, such as those performed by a trigger or a DML operation.

Constraints & Uncertainty

@future methods run in a separate transaction, which means they do not inherit the data context of the calling transaction. Governor limits (e.g., 50 @future calls per transaction) also apply, and the method can only accept primitive types or lists of them. Because the future method is executed after the original transaction completes, it must query the database again to retrieve any updated state.

Unresolved Questions

• Does an @future method start execution only after the original transaction has fully committed?
• Can the method retrieve the latest record values by re‑querying the database, or are there visibility constraints that prevent it from seeing changes made earlier in the same transaction?
• What is the recommended pattern to ensure an @future call processes the most recent data without violating governor limits?