It is all about certificates and trust.
In a no-ssl-inspection scenario a local computer trusts pre-installed certification authority (CA) certificates to verify the identity of a remote server (by it' s certificate) before establishing an encrypted connection utilizing the provided server certificate. The Fortigate can' t examine the encrypted content of this connection and may be unable to discover/rate the individual website accessed on a certain remote ip, especially if multiple different websites (virtual hosts) are hosted on it (as for example in CDNs).
In a certificate-inspection scenario, i.e. SNI information (http://en.wikipedia.org/wiki/Server_Name_Indication) from the TLS handshake between the local client and the remote server is evaluated. In most cases the Fortigate may be able to perform website rating based on this information to allow or disallow a connection to an individual website hosted on a remote server. The encrypted content of an allowed connection cannot be examined just as before. The traffic is not altered/modified too.
In a MITM full-inspection scenario you change the trust chain. A custom CA certificate is used on the Fortigate and also installed on the local PCs. When a local client attempts to connect to a remote server via SSL/TLS, the Fortigate intercepts the connection, generates and presents a fake but matching remote server certificate to the local clients they trust, because it can be verified by the custom CA certificate. This works with many, but not all applications. Since the encrypted connection is separately established between the remote server and the Fortigate and between the Fortigate and the local client, the traffic can now be examined/scanned for malicious/unwanted content.