@tuleap/fault's Fault type extends Record<string, unknown>. Originally, it was to allow code creating faults to set arbitrary properties, in order to distinguish them at error-handling time. Allowing custom properties means we can set some behaviour on a Fault, and in a completely different file / module / package, we can assert that behaviour, without having to import anything. It decouples the code creating Faults from the code handling them. For example, the code handling all kind of faults including API faults does not need to depend (via import) on the Fetch wrapper library. It can instead test a Fault instance for behaviours and make decisions based on the Fault alone.

That said, unknown allows anything, including Error, null, Object, etc. It seems the potential for misuse is too high. After gathering a bit of experience using @tuleap/fault, I suggest to only allow functions returning boolean or string. We must allow functions returning string because otherwise toString() would not be allowed. Most of the time, all we need is a boolean to distinguish among Faults. Having a function means we can do some checks, for example we can build a Tuleap API Fault that has a function isForbidden() that returns true if the status code is 403.