Review AI report join null keys and one-to-one cardinality

Choose the relation before attaching fields

A fictional AI report contains two draft records. A lookup supplies a harmless teaching category for each. The enrichment looks routine, but a missing key or duplicate lookup can attach the wrong category or change how many rows reach the summarizer. A syntactically valid table does not define the intended relation.

Select one bounded left enrichment through pandas.merge, with explicit ordinary columns tenant_ref and record_ref. Both inputs are independently admitted, non-confidential and server-scoped. The intended relation is one-to-one, and every left record requires a permitted counterpart. Index joins, implicit key selection, cross joins, coercion and repair fall outside this profile.

All examples and eight cards are PROPOSED_UNRUN. No DataFrame, Series, merge, null sentinel, query, dataset, model or runtime fixture was constructed or exercised. Paper labels describe proposed decisions, not observed library outputs.

Read the selected API contract without borrowing SQL assumptions

The actual pandas.merge reference, displaying pandas 3.1.0, warns that null keys on both sides match, unlike usual SQL joins. Without explicit on keys or index joining, the default is the common-column intersection. A left merge uses left keys. The documented one_to_one validation checks key uniqueness on both inputs; indicator distinguishes left_only, right_only and both. Many_to_many performs no validation checks.

Those documented distinctions motivate three separate application gates: key admission, relationship validation and match coverage. This worksheet implements none of them. It also makes no claim about an installed pandas release, extension dtype, importer or resource use.

Make missing identity a rejection, not a matching convention

For this proposed report, both key components must be approved bounded nonempty strings with an independently established exact representation. A missing component makes the row ineligible before the join. The complete supported intake adapter must establish that classification; a readable display or a guessed spelling for missing data cannot replace it.

Do not fill missing keys with a shared placeholder, normalize them into a neighboring object or silently remove inconvenient rows. Each choice changes the relation being reviewed. Record the rejected input identity and reason through a permitted minimized channel, then require corrected authorized source data.

The tenant component comes from trusted application scope, not the model. A matching pair cannot create permission to inspect another tenant’s lookup row. The tenant guide still controls which source records may enter either input.

Keep cardinality and required coverage separate

Our selected plan requires independently supported one-to-one validation and explicit keys. Reject duplicate keys on either side instead of relaxing the relationship, keeping the first duplicate or switching to a more permissive mode. A changed relationship needs a separately reviewed task.

Then reconcile the required left identities and their match dispositions. Two unique input sets can still contain different keys. Under this report’s policy, an unmatched required row holds the enriched result; it does not become an approved empty category or vanish from the report. A successful uniqueness check is not this completeness decision.

Keep the selected output fields explicit too. Unexpected overlapping fields or ambiguous source columns require review rather than trusting whichever similarly named value a later consumer picks. The existing batch guide supplies the wider manifest discipline; here it remains tied to this concrete enrichment.

Use an original two-record association sheet

Invent left identities L-A and L-B with trusted pairs (T-A, R-1) and (T-A, R-2). The admitted lookup lists R-2 before R-1. Its permitted categories are “public example B” and “public example A.” Display order is not the association rule.

The useful positive retains both left identities, exactly their permitted associations and supported matched dispositions. It depends on complete input revisions, required-key admission, the declared cardinality, bounded processing and current output rights. No joined report has been produced.

For a proposed receipt, retain input revisions and owners, fixed key list and types, key-admission status, validation disposition, complete expected left set, per-row match status and allowed output fields. Keep actual content outside routine diagnostics. Row count alone cannot explain which counterpart supplied a field.

Walk eight inert enrichment cards

Keep the implementation and evidence claims bounded

Actual dtype and missing-value classification, trusted input extraction, complete supported merge/result adapter, unique column contract, resource limits, stable revisions and current permissions are unimplemented and unknown. Missing required evidence blocks a real positive. Validation supplies no universal memory ceiling, tenant isolation, source authenticity or harmless-content guarantee.

This article provides no installation, executable merge expression, input repair, benchmark or alternative join engine. Existing schema, Unicode identity and CSV-consumer policies remain unchanged. Boundary is prelaunch with planned request-path checks, not a shipped report-enrichment or DataFrame authorization service. Its mock-policy evidence validates different behavior.