So, TLS promises to deliver three things: Authentication, Confidentiality, and Integrity.
Authentication means Alice knows this TLS connection is to Bob's server and (optionally, rarely used for HTTPS) Bob's server can have Alice's client prove who it is too.
Confidentiality is the obvious one, all this is encrypted, so Mallory can't tell what Alice sent to Bob or vice versa (but, from a position in the middle Mallory can see that Alice and Bob are communicating and put an upper bound on how much was sent each way)
Integrity means that Mallory also can't tamper with the messages. Even though Mallory doesn't know what they mean, in a lot of trivial encryption schemes, Mallory can tamper with it blindly. This won't work in TLS, if Mallory changes things randomly the connection just drops, and from the middle position dropping the connection was always possible anyway.
Now, back in older TLS versions it's usual for Integrity to be protected separately from Confidentiality via a MAC (Message Authentication Code). This is like a checksum, except cryptographic so that Mallory has no practical chance to guess a valid encrypted message other than the real one.
The TLSNotary scheme arranges that one party doesn't know the MAC used for their TLS session until after they've concluded the session and handed a transcript to another party. Since they didn't know the MAC they could not have faked the transcript.
This won't work in modern TLS because we don't use MACs. Instead a scheme like AES GCM is used, in which both confidentiality and integrity are protected by a single key in the same operation. This turns out to also improve the security ergonomics, it's much less tempting to do things that are a bad idea because those things are now hard whereas doing it properly is easy. However, since a single key is used, the TLSNotary scheme is not possible.