Replace assertion-based trust with runtime validation

Understand the likely causes

• Type assertions are erased and perform no general runtime conversion or schema validation. Interfaces and generic parameters are also erased. JSON syntax validity is separate from object shape, and a numeric field type is separate from finite integer or range requirements. A claimed user-defined predicate can be wrong as well if its implementation does not check the required properties.
• A value can pass a shallow shape check and still be unauthorized, too large, or mutable through another alias. Validation, normalization, permission, and stable ownership are distinct responsibilities. Choose explicit error handling for malformed syntax and rejected domain values rather than relying on whatever exception a later method happens to throw.

Identify what the assertion actually promises

The intentionally flawed excerpt asserts a numeric count even though the JSON contains text. It can pass the static checker because the author made that claim; the assertion does not inspect or convert the property. The snippet is marked non-runnable and has no promised successful output. Do not replace the assertion with any or another cast. Write down the real accepted shape and numeric domain before constructing a repair.

export {};
const data = JSON.parse('{"count":"3"}') as { count: number };
console.log(data.count.toFixed(0));

Decode the actual unknown value

The correction starts at unknown, rejects null and non-objects, checks the required field, and validates a safe integer range. It returns a new selected object so unrelated fields are not accidentally propagated. The ordinary parsed-JSON assumption matters: arbitrary proxies or getters need an additional property-access policy. No assertion is required because runtime observations provide the narrowing evidence. A real caller should also catch JSON syntax errors before passing a parsed value to this decoder.

export {};
type CountData = { count: number };
function decode(value: unknown): CountData | undefined {
  if (typeof value !== "object" || value === null || !("count" in value)) { return undefined; }
  const count = value.count;
  if (typeof count !== "number" || !Number.isSafeInteger(count) || count < 0 || count > 100) { return undefined; }
  return { count };
}
const valid: unknown = JSON.parse('{"count":3}');
const invalid: unknown = JSON.parse('{"count":"3"}');
console.log(JSON.stringify(decode(valid)));
console.log(decode(invalid) === undefined);

{"count":3}
true

Maintain validity after successful decoding

Decide whether extra fields are ignored, selected away, or rejected. Define normalization separately if numeric text should be accepted; do not silently expand the domain. Bound arrays and nesting to application needs, and ensure validated mutable data cannot be changed unexpectedly through aliases before use. For a public endpoint, enforce authorization after identifying the trusted actor. A sophisticated output type does not perform any of those operations. Use structured errors if callers need field categories rather than a single undefined result.

Keep it from recurring

• Mark untrusted boundaries as unknown, require executable validation before domain use, and review assertions as explicit trust claims. Maintain negative fixtures and distinguish validation from authorization and output filtering.