Working draft / Open decisions

A shared format needs
shared behavior.

The first review found seven areas where existing readers differ. They are documented here so the specification can resolve them explicitly.

These are unresolved decisions, not claims of completed fixes. The strict-v0.1 inspection profile is one deliberately bounded interpretation. It is not a declaration that every existing reader already agrees.

CBFP-DIFF-01

Portable identity

Readers accept different identity lengths and character cases; some accept local provider keys in places where other readers expect an exact file hash.

What needs to agree

Agree on portable identity, case handling and migration of local keys. Test lengths, case, nonhex values and filename / manifest / MAIN agreement.

The inspection profile requires exactly 64 lowercase hexadecimal characters.

CBFP-DIFF-02

Partial landmark records

Some matching decoders discard trailing bytes; stricter intake rejects them. The same input can therefore be treated differently at separate boundaries.

What needs to agree

Agree on malformed, empty and partial input behavior, count agreement and canonical base64. Test 7-, 8-, 9-, 15- and 16-byte buffers.

The prototype rejects partial records. AQAAAAIAAAAH decodes to nine bytes and is rejected.

CBFP-DIFF-03

Record sampling

Existing implementations retain different landmark indices when reducing a long fingerprint to a record budget.

What needs to agree

Select the sampling rule and qualify existing fingerprints. Compare retained bytes and matching evidence at the start, middle and end of a recording.

For ten records reduced to four, examined readers select [0, 2, 5, 7] or [0, 2, 4, 6].

CBFP-DIFF-04

Signed anchor frames

A frame with the high bit set can be interpreted as a large positive value or a negative value by different readers.

What needs to agree

Approve a common frame domain and overflow policy. Test zero, the signed maximum, the first high-bit value and the unsigned maximum.

The prototype rejects frame values greater than 2³¹ − 1.

CBFP-DIFF-05

Resource bounds

Compressed and inflated byte limits, track counts and span counts differ among current readers.

What needs to agree

Define a portable writer profile and importer limits. Check actual byte bounds, malformed archives and whether one invalid track rejects an entire bundle.

The profile caps bundles at 48 MiB compressed and 32 MiB inflated, with 2,000 tracks and 20,000 spans per MAIN.

CBFP-DIFF-06

Defaults, IDs & timing

Readers differ on omitted fields, empty span IDs, default values and invalid time intervals.

What needs to agree

Define reject, preserve or migrate behavior. Test import → edit → reopen without losing persistent IDs or changing the intended filtering action.

The prototype requires nonempty unique IDs and valid intervals; those stricter choices are not an approved universal contract.

CBFP-DIFF-07

Extensions, admission & trust

Parsing unknown fields, accepting server submissions, authenticating content and authorizing transcripts are different operations. Existing paths do not have identical rules.

What needs to agree

Test extensions, versions, duplicate keys, reserved signatures and paired transcript permissions at their real boundaries. Never equate parsing with full coverage or trust.

The prototype retains unknown metadata but does not verify signatures, authorize sharing or establish playback eligibility.

Evidence & scope

The draft draws from the original source audit and the first SDK review. These are reference snapshots, not a qualification of today’s deployed native builds.

ReferenceReviewed commit
Python inspection SDKc3a69c1
Initial specification draftff17f97
Core1fd436fe678afe8dd6f9ca076148d89caaa166c5
Server04e1ca2fe367f738eaa899fa1a0d0b8c3d20f8fa
Androidca427b2521ff5cde64a078ee57d28cf53d870807

The same decisions are cross-referenced in the project’s core, systems-model and state-machine review documents. Resolving them requires an agreed contract and tests against the actual native readers and writers, not just a documentation update.

The first SDK review passed 30 tests using its own inspection implementation and synthetic vectors. Acoustic generation, matching and cross-language interoperability remain unqualified SDK capabilities.

Read the licensing status →