Small surface, conservative claim.

The parser is already used in production-oriented Nift and Minify++ code, but Jsonic++ as an independent project is new. Those are two different kinds of evidence, and this page keeps them separate.

What is already strong

• the implementation is compact enough to audit as one header;
• normal parsing rejects duplicate keys and malformed JSON instead of applying permissive recovery;
• Unicode escape/surrogate behavior has explicit test coverage;
• parse failures include source location;
• sanitizer-backed tests can exercise the standalone implementation;
• the maintained lifetime corpus passes ASan/LSan/UBSan, native RSS-soak and independent Valgrind gates with all allocations released at exit;
• the same parser semantics are already dogfooded by larger Nift and Minify++ codebases.

What “used by Nift and Minify++” proves

It proves more than a toy example: the parser is exercised in real configuration/build-tool paths, has survived changes driven by those consumers, and is integrated into projects with their own regression expectations. It also creates useful pressure for deterministic behavior and small dependency cost.

It does not prove that every independent Jsonic++ use case has been explored. Nift and Minify++ naturally exercise the shapes of JSON they need. A public library eventually encounters different file sizes, object shapes, error-reporting expectations, toolchains and calling styles.

What independence still needs to earn

A standalone library should accumulate its own external conformance, sustained fuzzing, packaging/toolchain coverage, API-stability history and downstream-user evidence. The relevant question is not “can we add more features?” but “have the current guarantees been attacked from enough independent directions?”

Risk profile

Choosing it responsibly

Jsonic++ is easiest to justify when dependency weight and auditability matter, the Document model fits the application, and the project can pin/vendor a known version. If you need decades of ecosystem history, extensive serialization adapters, exact arbitrary-size numeric models, JSON Pointer/Patch, schema integration or broad package-manager support, a larger mature library may be the more responsible choice.

Release discipline

Parser changes should arrive with permanent regression evidence and synchronized downstream validation. Production-readiness claims should follow evidence rather than version numbers: a small library does not become “enterprise ready” merely because it reaches 1.0.