Proof Architectures for Presence Adjudication

Not every Presence Adjudication System contains a sophisticated proof architecture.

A witness statement is a form of evidence, but it is not usually described as a proof architecture. A regulator’s record may settle an issue, but the evidentiary form remains largely institutional rather than formally structured. A centralized digital platform may log location events, but often leaves the interpretation of those logs to internal systems and operator discretion.

Type 6 Presence Adjudication Systems are different. They operate in environments where multiple parties may need to rely on consequential claims of presence without sharing the same institution, trusting the same operator, or accepting broad disclosure of raw traces. In such settings, the architecture of proof becomes much more important.

This page is concerned with that architecture.

Its purpose is not to argue that proof systems alone solve the larger problem of presence adjudication. They do not. Proof is one part of a broader evidentiary and institutional structure. But it is an increasingly important part, because the shape of the proof architecture influences what kinds of claims can be expressed, what kinds of privacy can be preserved, what can be verified formally, and what remains dependent on trust, governance, or dispute.

PAS and PPS

A useful distinction is needed at the outset.

A Presence Adjudication System (PAS) is the broader system by which presence claims become socially and institutionally usable. It includes not only evidence formation and verification, but also adjudication, dispute, finalization, and the rules by which outcomes become durable enough for others to rely upon.

A Presence Proof System (PPS) is narrower. It is the evidentiary subsystem that transforms measurements or observations into a verifiable claim about presence.

In simplified form:

• PPS answers: how is the claim proven?
• PAS answers: how does the claim become relied upon?

This distinction matters because a system may have a strong PPS and still have a weak PAS. It may produce elegant proofs, yet remain fragile in dispute, poorly governed, or vulnerable to finality failure. Conversely, a system may have strong institutions and weak proof structure, relying more on authority than on formal evidentiary discipline.

The focus of this page is PPS in that narrower sense: the architectures by which presence claims can be formally supported inside a larger PAS.

Why Proof Architecture Matters

A presence claim is not self-interpreting.

To say that a person, device, or asset was within a region during an interval is already to move from the physical world into a structured proposition. The question is how that proposition is supported.

In weak systems, support often takes the form of raw traces, operator logs, screenshots, manually assembled records, or private database entries. These may be usable, but they do not provide much formal discipline. They usually reveal more than necessary, depend heavily on institutional trust, and become awkward under dispute.

A proof architecture matters because it changes the evidentiary form of the claim.

Instead of asking a relying party to inspect broad telemetry and infer what happened, the system can ask a narrower question:

can this proposition be shown to hold under explicit rules, using evidence that is verifiable at the level the claim requires?

That shift is foundational. It moves the system away from raw observation alone and toward structured evidentiary claims.

The General Shape of a Presence Proof System

A Presence Proof System can be understood as a chain with several stages.

Stage	Function
Observation	Physical signals or observations enter the system
Claim formation	The relevant proposition is defined
Evidence construction	Observations are transformed into a provable evidentiary form
Proof generation	A proof or structured evidence object is produced
Proof verification	Another party checks that the claim follows under the relevant rules

Not every PPS makes these stages equally explicit, and not every system draws the boundaries in the same way. But this basic progression is useful because it shows where architectural choices arise.

A system may differ in:

• how observations are trusted
• how claims are bounded
• how much data must be revealed
• whether the proof is interactive or non-interactive
• whether the proof is public or private
• whether the proof is purely formal or partly institutional
• whether verification is deterministic or judgment-laden

These differences define the proof architecture.

Major Architectural Families

Several broad families of proof architecture recur in presence systems. These are not mutually exclusive, and mature systems may combine them.

Trace-Based Proof

In trace-based architectures, the proof is effectively the trace itself, or a large portion of it.

A prover discloses raw location data, timestamps, movement history, or device logs, and the relying party inspects these materials to infer whether the claim is satisfied.

This is still the dominant pattern in many real-world systems because it is operationally straightforward and easy to understand. But it has serious weaknesses. It over-discloses by default, scales poorly under dispute, and often leaves interpretation inseparable from institutional judgment.

It is best thought of as a low-maturity evidentiary architecture: sometimes useful, often unavoidable, but structurally weak as a long-term foundation.

Attestation-Based Proof

In attestation-based architectures, a trusted party or trusted device asserts that the claim is true or that relevant measurements were observed.

Examples may include:

• signed device attestations
• secure hardware reports
• witness attestations
• inspector certifications
• trusted measurement providers

This architecture can improve integrity and reduce the need to expose raw traces directly. But it shifts the trust burden onto the issuer of the attestation. The proof becomes strong only to the extent that the attesting party or hardware root is itself trusted.

Attestation-based systems are therefore often useful components, but rarely complete answers on their own.

Predicate-Based Cryptographic Proof

In predicate-based architectures, the system proves not the underlying data itself, but that the data satisfies a defined condition.

This is where cryptographic proof systems become especially important. Instead of revealing all coordinates or measurements, the prover may establish that:

• the measurements are consistent with being within a region
• the claim falls within a time window
• a path crossed a threshold
• a device did not leave a zone during a bounded interval

This architecture is central to the privacy-preserving ambitions of Type 6 PAS because it allows the evidentiary object to be the claim rather than the trace.

Its value is considerable, but its limits should be kept in view. Such a proof can still depend on trusted observations, careful rule design, and the institutional mechanisms surrounding verification and dispute.

Commitment-and-Reveal Architectures

In these architectures, underlying measurements or claim data are first committed to in a binding form and only selectively revealed later if needed.

This can be useful where:

• the system wants to preserve evidence without exposing it immediately
• disputes may require later escalation
• challengers need confidence that hidden data existed at the relevant time
• finalization depends on proving that records were not altered after the fact

Commitments can strengthen integrity and support future dispute resolution, but they do not by themselves prove that the committed data is true. They solve one part of the problem: the stability of evidence over time.

Hybrid Architectures

Most serious systems are likely to be hybrid.

A mature PPS may combine:

• signed measurement sources
• commitments to raw observations
• predicate proofs for ordinary adjudication
• selective reveal under dispute
• verifier checks for rule compliance

This is often the most realistic path for Type 6 PAS. Pure architectures are elegant to describe, but real systems usually need layered evidentiary forms because no single mechanism solves every aspect of the problem.

The important question is not whether the architecture is pure. It is whether the different layers fit together coherently.

The Central Design Tension

Proof architectures are shaped by a central tension:

Should the system prove the data, or prove the claim?

This is one of the deepest design choices in the entire section.

A system that proves the data tends to maximize inspectability at the cost of privacy and boundedness.

A system that proves the claim tends to support better disclosure discipline, but also demands more sophistication in proof construction, clearer claim semantics, and stronger confidence that the underlying measurements were handled correctly.

Type 6 systems matter in part because they are among the few PAS types capable of making the second path viable at scale.

That does not mean the first path disappears. Some disputes, escalations, or legal contexts may still require richer evidentiary access. But if the ordinary architecture is built around proving the data rather than proving the claim, then overexposure tends to remain the norm.

Public Proofs, Private Proofs, and Layered Disclosure

Not all proofs are disclosed in the same way.

A proof architecture may be:

• public, meaning the relevant proof object can be checked by any party with access to it
• private, meaning only designated parties can verify or interpret the proof
• layered, meaning ordinary adjudication uses bounded proof, while deeper evidence remains available only under challenge or escalation

Layered disclosure is especially important for Type 6 systems because it avoids a false choice between “show everything” and “show nothing.” A system may allow routine claims to be assessed at a narrow level while still preserving a structured path for deeper inspection when disputes justify it.

This is often a more mature model than either total exposure or total concealment.

Proof Architecture Does Not Remove Measurement Risk

One of the most common conceptual errors in this space is to assume that a strong proof architecture makes a presence claim trustworthy all the way down.

It does not.

A proof system may perfectly establish that a claim follows from a set of inputs. But if those inputs were fabricated, spoofed, or poorly grounded in physical reality, the overall evidentiary result remains weak. The proof may be valid while the claim remains false in a real-world sense.

This is why proof architecture must always be understood in relation to:

• measurement trust
• prover incentives
• verifier incentives
• dispute design
• governance
• finality

A PPS is not the whole PAS.

It can discipline one critical part of the system — the form in which evidence is presented and checked — but it cannot redeem weakness everywhere else.

Proof Architecture and Dispute

A strong proof architecture should also be designed with disputes in mind.

This means asking not only:

• how is an ordinary claim proven? but also:
• what happens when the claim is contested?
• what evidence can be reopened?
• what remains hidden?
• what can be challenged formally?
• what requires institutional judgment?
• what additional disclosure, if any, is possible under escalation?

A proof system that works beautifully in undisputed cases but collapses under challenge is not yet mature. It may still be useful, but it has not fully solved the evidentiary problem.

This is why commitment layers, structured escalation, and challenge-compatible claim formats often matter as much as the ordinary proof itself.

Evaluating a Presence Proof Architecture

A PPS should be judged by questions such as these:

Dimension	Question
Claim boundedness	Does the system prove a narrow proposition or require broad data exposure?
Measurement dependence	How much trust is still placed in hidden inputs or attestors?
Privacy discipline	How much is revealed in ordinary use?
Proof soundness	Does the proof actually establish the intended claim?
Verification cost	How expensive is it to check the proof?
Dispute compatibility	Can the architecture support challenges and escalation?
Replayability	Can later parties understand what was proven and under what rules?
Portability	Can the proof travel across institutional boundaries?
Adjudicative fit	Is the proof usable inside a broader PAS, not just elegant in isolation?
Composability	Can the proof architecture coexist with other evidentiary layers?

These questions matter because many proof systems are impressive in abstraction but poorly matched to the institutional life of real claims.

What a Good Proof Architecture Looks Like

A good proof architecture for a Type 6 PAS does not simply maximize formal sophistication.

It does something more demanding. It makes the right claim provable at the right level of disclosure, while remaining compatible with challenge, replayability, and durable adjudication.

In practice, that often means:

• proving bounded propositions rather than exposing broad telemetry
• minimizing ordinary disclosure
• preserving stronger evidentiary options for disputes
• making proof validity legible to verifiers
• reducing discretionary interpretation where possible
• avoiding silent dependence on hidden institutional trust
• fitting cleanly into a larger PAS that can adjudicate and finalize outcomes

That is a much higher standard than “uses cryptography” or “supports zero-knowledge.”

Why This Matters for the Rest of the Design Space

Proof architectures sit at the center of the Design Space section because they connect directly to almost every other issue.

They shape privacy and verifiability by determining what is proven and what must be shown.

They shape trust models by determining which assumptions remain formalized and which remain institutional.

They shape disputes by determining what can be reopened and what must be accepted as fixed.

They shape finality by determining what exactly becomes durable and replayable.

And they shape governance because protocol parameters often determine claim semantics, proof thresholds, admissible evidence, and escalation conditions.

That is why proof architecture is not a technical subtopic for specialists alone. It is one of the main ways a Type 6 PAS expresses its view of evidence.

Conclusion

A Presence Proof System is not the whole of a Presence Adjudication System. But it is one of the places where a system’s evidentiary philosophy becomes visible.

Weak architectures treat presence as something to be inferred from broad records after the fact. Stronger architectures aim to make bounded claims directly provable under explicit rules, with disclosure disciplined to the needs of the claim rather than the appetites of the observer.

That is the deeper significance of proof architecture in this field.

It is not only about formal correctness. It is about deciding what kind of evidentiary object a presence claim should become.

And for Type 6 systems, that choice is fundamental.