One way to model this kind of logic is to use a union type, something like this

interface Valid {
  isValid: true
}

interface Invalid {
  isValid: false
  errorText: string
}

type ValidationResult = Valid | Invalid

const validate = (n: number): ValidationResult => {
  return n === 4 ? { isValid: true } : { isValid: false, errorText: "num is not 4" }
}

The compiler is then able to narrow the type down based on the boolean flag

const getErrorTextIfPresent = (r: ValidationResult): string | null => {
  return r.isValid ? null : r.errorText
}

To avoid creating multiple interfaces which only get used to create a third, you can also alternate directly, with a type instead:

type ValidationResult = {
    isValid: false;
    errorText: string;
} | {
    isValid: true;
};

The union demonstrated by bugs is how I recommend handling this. Nonetheless, Typescript does have something known as “conditional types,” and they can handle this.

type ValidationResult<IsValid extends boolean = boolean> = (IsValid extends true
    ? { isValid: IsValid; }
    : { isValid: IsValid; errorText: string; }
);


declare const validation: ValidationResult;
if (!validation.isValid) {
    validation.errorText;
}

This ValidationResult (which is actually ValidationResult<boolean> due to the default parameter) is equivalent to the union produced in bugs’s answer or in CertainPerformance’s answer, and can be used in the same manner.

The advantage here is that you could also pass around a known ValidationResult<false> value, and then you wouldn’t have to test isValid as it would be known to be false and errorString would be known to exist. Probably not necessary for a case like this—and conditional types can be complex and difficult to debug, so they probably shouldn’t be used unnecessarily. But you could, and that seemed worth mentioning.