libLogit

Binding Compatibility Matrix

This page is the binding-by-binding reality check for libLogit v1 Beta work. It complements the broader language matrix by focusing on behavioral compatibility rather than package maturity alone.

What This Matrix Tracks

For each Alpha MVP binding, this page tracks:

blank LOGIT behavior
config loading
direct and builder-style logging
explicit flush/close lifecycle controls
directory-mode and remote-path baseline behavior
advanced runtime feature status
how unsupported advanced behavior is currently handled

Status Vocabulary

Term	Meaning
Yes	Public behavior exists and is supported by local repo evidence.
Partial	Some related behavior exists, but the full portable Beta expectation is not yet met.
No	The current binding does not expose that behavior as a public feature.
Waived	The feature is explicitly not required for this binding in the current shared conformance report.

Lifecycle And Baseline Behavior

Binding	Blank LOGIT	Config loading	Direct log call	Builder/stream call	Explicit logger flush	Explicit logger close	Directory mode	Remote-path-as-file
Python	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
C++	Yes	Yes	Yes	Yes	Partial	No	Yes	Yes
C	Yes	Yes	Yes	Yes	No	No	Yes	Yes
C#	Yes	Yes	Yes	Yes	No	No	Yes	Yes
Java	Yes	Yes	Yes	Yes	No	No	Yes	Yes
JavaScript	Yes	Yes	Yes	Yes	No	No	Yes	Yes
Go	Yes	Yes	Yes	Yes	No	No	Yes	Yes
Kotlin	Yes	Yes through Java	Partial via wrapper/delegate	Yes	No	No	Yes	Yes through Java delegate

Advanced Runtime Features

The current advanced-feature status comes from the documented conformance policy source:

tests/conformance/binding-capabilities.json

Binding	Redaction	Buffering	Failure policy	Database retention
Python	Passed	Passed	Passed	Passed
C++	Waived	Waived	Waived	Waived
C	Waived	Waived	Waived	Waived
C#	Waived	Waived	Waived	Waived
Java	Waived	Waived	Waived	Waived
JavaScript	Waived	Waived	Waived	Waived
Go	Waived	Waived	Waived	Waived
Kotlin	Waived	Waived	Waived	Waived

What “Explicit Logger Flush” Means Here

This column is intentionally narrow.

It does not ask whether the language runtime eventually flushes a file handle. It asks whether the binding exposes a public logger-level operation equivalent to:

LogIT.flush()

Current evidence:

Python: yes, explicit flush() is part of the public object surface.
C++: partial, because the message builder has explicit flush()/commit(), but the logger object itself does not expose a matching public lifecycle API.
the other baseline bindings currently rely on immediate writes and builder commit, not a separate logger-level flush surface.

What “Explicit Logger Close” Means Here

This column tracks whether the binding exposes a public logger-level close or dispose action for persisted resources.

Current evidence:

Python: yes, explicit close() is public and covered by tests.
the other baseline bindings do not currently expose a comparable logger-level close API in the same public way.

That does not mean the bindings are unusable. It means full lifecycle parity is still Beta work.

Unsupported Advanced Behavior

Here is the current honest product story:

Python

advanced runtime fields are real
they have direct test coverage
they are part of the strongest retained-store/reference path today

Other MVP bindings

advanced runtime parity is not yet required in the shared report
those features are currently waived rather than claimed
the bindings should be treated as strong baseline logging implementations, not as full parity implementations of Python’s advanced runtime feature set

Why This Matters

Without a page like this, “portable SDK” can sound broader than the actual binding evidence.

With this page, a developer can quickly distinguish:

what the portable baseline already proves
what the Python reference binding proves alone
what still needs lifecycle and advanced-feature parity before Beta can claim stronger language agnosticism