Semafide

Appraisals and automated valuations get challenged years after they run. By then the data they used may have changed, been corrected, or disappeared, and rerunning the analysis can produce a different number. Semafide is testing whether independent custody can preserve enough evidence to establish what actually happened.

Mortgage lending is the first market this is tested against, not the only one, because it was inexpensive to test.

What a partner should look at first

Not a library clone. One sealed run, and what an examiner is allowed to say about it.

python -m seal.demo_60s walks an honest valuation on assignment ASG-8942, then two attacks. On the honest case the verifier prints:

HONEST EXECUTION (Collateral Valuation #ASG-8942)
------------------------------------------------------------------------
  Precedence              ✓ ESTABLISHED
  Witness attestation     ✗ NOT ESTABLISHED
  Recipe available        ✓ ESTABLISHED
  Recipe reproduced       ✓ ESTABLISHED
  Historical execution    ✗ NOT ESTABLISHED
  Completeness            ✗ NOT ESTABLISHED
------------------------------------------------------------------------
  CRYPTOGRAPHIC RESULT    ✓ ESTABLISHED
  EVIDENTIARY RELIANCE    ✗ NOT ESTABLISHED

An examiner can say the evidence commitment predates the seal, and that a pinned recipe later reproduced the sealed output. An examiner cannot say a witness observed the run, that historical execution is established, or that this was the only run in the assignment. Cryptographic integrity is not evidentiary reliance.

That refusal is the product. The rest of this README is the argument underneath it.

See it run (sixty seconds, built for someone outside the project):

cd code
pip install -r seal/requirements.txt
python -m seal.demo_60s

Talk: eli@semafide.com

Built / unbuilt

The intended architecture places the evidentiary record outside the control of the party that produced the analysis.

What an examiner can and cannot say

The verifier records five independent propositions. They are not a ladder.

Successful re-derivation does not make historical_execution_established true. A generic signature over a supplied bundle does not make witness_attestation true.

This table and docs/claim-vocabulary.md are the source for these five names.

Further reading, after the table: docs/demos/README.md (worked example to architecture), docs/executive-thesis.md (commercial thesis), and the system map generated from docs/semafide.architecture.json. The interactive design canvas assumes this table.

The problem

Mortgage valuation increasingly relies on software and data sources that can change after an analysis runs. Automated valuation models can use public records, listings, market data, and other inputs. Appraisers can use statistical analysis and regression-based methods to support adjustments. The underlying data, tools, and model versions may change, be corrected, or become unavailable.

When a repurchase demand, regulatory examination, or dispute arrives later, rerunning the analysis can produce a different result. The historical execution may have depended on a state that is no longer available in the same form.

The interagency Quality Control Standards for Automated Valuation Models became effective October 1, 2025. For covered mortgage originators and secondary market issuers, the rule requires policies, practices, procedures, and control systems designed to comply with specified quality-control standards, including protection against the manipulation of data. The rule does not itself prescribe Semafide's evidence model. Separately, Fannie Mae's Selling Guide requires appraisal reports dated on or after March 1, 2025 to summarize the data sources, tools, and techniques used to support time adjustments. Semafide's narrower question is whether the underlying execution state can later be established rather than merely asserted.

Authorization and admissibility

Authorization is prospective and structural. It asks whether an action is permitted and whether the output conforms: schema validity, licence currency, a passing risk score, the required checks completed.

Admissibility asks a different question. If a transaction is challenged three years from now, can the data state it rested on be established?

The question is adjudicated retrospectively, but the evidence needed to answer it has to be preserved prospectively. An analysis cannot be made historically reproducible after the relevant state has disappeared. The system that produced the analysis also cannot provide independent evidence of the completeness of its own record without some external control over that record.

The principle

A record showing that an analysis and its inputs sat together in one file is not evidence that the output was derived from those inputs at that moment. Co-occurrence is not binding.

A prior evidence commitment establishes precedence: the evidence commitment existed in the chain before the run seal that names it. That rules out selecting the committed evidence after seeing the output. It does not by itself prove that the analysis actually consumed those inputs.

Why custody rather than a file

The obvious design hands the appraiser or institution a signed artifact to keep. A signature does not solve completeness.

A signature proves that what a document contains has not been altered, assuming the signing key and verification process are trusted. It cannot prove that the document contains everything. Completeness is a claim about what is absent, and the party deciding what to disclose can also decide what to omit. Run five analyses, seal all five, and disclose the three that support the conclusion. Each of the three can verify perfectly. Nothing inside them establishes that the other two existed.

Timestamping does not close this. A timestamp can establish that a particular document existed by a stated time. It says nothing about documents nobody was shown. Timestamp all five runs and hand over three, and all three still verify.

Splitting the work across five separate records does not help. Each record can be internally complete and authentic while the disclosure remains incomplete.

The intended custody architecture addresses that problem by putting assignment-level disclosure outside the control of the party being examined. An examiner can then ask the custodian how many runs and records it received and compare that statement with the supplied artifact. This is a custody property, not something a signature alone provides.

The same limit applies to watermarks and to Content Credentials, which travel attached to the artifact and therefore remain with whoever chooses which artifacts to hand over. Longer version in docs/watermarking.md.

The current repository implements the verification side of that model, plus a capture scaffold that seals a decorated function call into a chain and self-checks it against that verifier. It does not implement a hosted production custody service, and the capture scaffold does not enforce that every run in an assignment reaches the chain: an undecorated call is invisible, and a manifest never handed to a custodian is not one anybody can count.

How the intended architecture integrates

Semafide sits at the application boundary. Upstream analytical software would submit an execution manifest carrying the evidence commitment, parameter set, tool and model version, and output.

The manifest can also carry a re-derivation recipe. The current schema requires a pinned endpoint and version, the exact invocation, the input reference, the expected output digest, and a service window. A verifier can later execute the recipe and compare the produced output with the sealed output when the partner still serves that environment.

Successful re-derivation establishes reproducibility of the claimed execution recipe. It does not, standing alone, establish that the historical execution used that recipe. Historical capture and custody are the remaining operational layer.

The intended examiner workflow has two distinct statements. One concerns the supplied chain and its completeness. The other concerns the assignment-level disclosure: how many chains the assignment contains and what the custodian says it holds. The latter must come from a party other than the sealer. Without that independent statement, the verifier reports that assignment disclosure was not checked rather than treating the artifact as complete.

Each analysis is committed to its assignment when the chain opens, rather than being assigned at certification. The anchor fixes the assignment before later entries are added. This prevents a completed chain from being relabelled after the fact. It does not establish that the assignment contains no sibling chains; that requires an assignment-level disclosure from outside the chain.

External time

The time a record states is a value chosen by its author. A chain assembled today can therefore contain timestamps from last year and still have internally valid signatures.

A conventional timestamp authority addresses a different side of the problem. It can establish that a particular document existed no later than the time asserted by the timestamp token. It does not establish that the document did not exist earlier.

The repository therefore models two external bounds. An upper bound comes from an external time authority. A lower bound comes from a published unpredictable value that could not have been known before it was issued. If both are available and independently resolved, the verifier reports the resulting interval rather than treating the author's timestamp as historical proof.

The current package models these bounds but does not itself provide a production RFC 3161 service or a production beacon. Those are deployment dependencies.

What it does not do

Custody, not judgment.

The intended record is symmetric evidence. It should document a flawed analysis as faithfully as a sound one. It does not establish that the inputs were well chosen, that an appraisal conclusion was correct, or that an automated decision was substantively sound.

It also does not claim that successful re-derivation proves historical execution. The strongest historical claim requires capture at the time of execution and a custody arrangement that prevents the interested party from selecting the evidence after seeing the outcome.

Custody carries costs that a file handed over does not. A production guarantee would depend on Semafide continuing to operate, a custodian preserving the records it received, and partners keeping pinned execution environments available. Those are operational and contractual dependencies, not consequences of cryptography alone.

Collusion remains an operational question. An append-only log can make later equivocation detectable when its consistency proofs are checked. Independent witnesses can make conflicting views harder to maintain without detection. The deployment still has to establish who the witnesses are, whether they are independent, and whether anyone checks what they signed.

About this repository

code/seal/ contains the artifact schema, checkpoint formats, external time-bound models, append-only log primitives, witness machinery, standalone verifier, and a capture scaffold (code/seal/capture/) that seals a live function call into a real artifact and self-checks it against the verifier. It holds one chain open per assignment so that sequence numbers and prev-hash linkage run unbroken across calls, which makes an omitted run detectable rather than merely undesirable. What it does not do is site a witness on the operator's machine or establish how many runs an assignment holds: the decorator is opt-in per function, an undecorated call is invisible, and a chain never handed to a custodian is not a chain anybody can count. There is no hosted production custody service.

The verifier reports the epistemic propositions above and nothing else in that register. An earlier revision of this package also exposed BindingLevel, a single derived value that collapsed the five propositions into one rung on a lossy summary ladder; it has been removed, since it could not even represent the strongest of the five claims and every place it could mislead a reader was easier to fix by removing it than by re-caveating it again.

The verifier also reports chain completeness, assignment disclosure, external time bounds, and input-retention determinations. These answer different questions. Completeness asks whether a supplied chain is whole. Disclosure asks whether the chain is the whole assignment. Anchoring asks what external evidence constrains when the chain existed. Retention asks whether the operator could have kept the input, which determines whether re-derivation provides something beyond a locally retained and timestamped copy.

A green verification result is not a claim that the underlying model, appraisal, or business decision was correct. It means the artifact satisfied the particular checks the verifier performed against the evidence supplied to it.

The package also documents known limits. The current re-derivation recipe pins the endpoint, tool, version, invocation, input reference, output digest, and service window, but does not yet pin the full execution environment, numerical libraries, hardware, or linked BLAS. A later mismatch can therefore reflect environmental drift rather than a changed analysis. The verifier fails conservatively rather than converting that uncertainty into a clean pass.

The package deliberately does not present its experimental transparency-log implementation as a production foundation. Production deployments should use established transparency-log and witness specifications rather than treating this scaffold as a replacement for them.

It depends on cryptography alone.

Reproduce the verifier

git clone https://github.com/besscog13/semafide-seal.git
cd semafide-seal
pip install -e .

python -m seal.demo    # the guided walkthrough
python -m seal.demo_60s # a 60-second external-facing walkthrough: honest execution, tamper detection, and a selective-disclosure attack

The demo exercises the verifier against cases including truncation, assignment-level disclosure, retention determinations, and time-bound failures. It is the fastest way to see what the verifier refuses to grant.

demo_60s is a shorter presentation layer over the same real verifier, built for showing someone outside the project what it establishes and what it catches, rather than for diagnostic depth.

To run the checks yourself:

pip install -e ".[test]"
pytest                                      # unit, adversarial, and property-based tests

pip install -e ".[specs]"
python specs/SPEC_merkle_consistency.py     # each spec exits 0 or 1

What the demo prints

python -m seal.demo_60s, verbatim:

------------------------------------------------------------------------
  SEMAFIDE
  EXECUTION EVIDENCE DEMO
------------------------------------------------------------------------

HONEST EXECUTION (Collateral Valuation #ASG-8942)
------------------------------------------------------------------------
  Precedence              ✓ ESTABLISHED
  Witness attestation     ✗ NOT ESTABLISHED
  Recipe available        ✓ ESTABLISHED
  Recipe reproduced       ✓ ESTABLISHED
  Historical execution    ✗ NOT ESTABLISHED
  Completeness            ✗ NOT ESTABLISHED
------------------------------------------------------------------------
  CRYPTOGRAPHIC RESULT    ✓ ESTABLISHED
  EVIDENTIARY RELIANCE    ✗ NOT ESTABLISHED
  ↳ Cryptographic integrity is established, but the evidence vector
    does not establish every claim required for historical reliance.

ATTACK: POST-HOC INPUT SUBSTITUTION
Scenario: Operator alters the committed action after execution.
------------------------------------------------------------------------
  Original evidence       COMMITTED
  Altered input            NOT DETECTED
  Commitment relation      ✗ BROKEN
------------------------------------------------------------------------
  CRYPTOGRAPHIC RESULT    ✗ NOT ESTABLISHED
  EVIDENTIARY RELIANCE    ✗ NOT ESTABLISHED
  ↳ Mechanism: the verifier detects that the claimed execution no longer
    agrees with the committed evidence.

ATTACK: SELECTIVE ASSIGNMENT OMISSION
Scenario: Operator ran 3 models but presents only the favorable run.
------------------------------------------------------------------------
  Runs committed          3 (independent assignment record)
  Runs disclosed           1 (presented by operator)
  Assignment disclosure    ✗ NOT ESTABLISHED
------------------------------------------------------------------------
  CRYPTOGRAPHIC RESULT     ✓ ESTABLISHED
  EVIDENTIARY RELIANCE     ✗ NOT ESTABLISHED
  ↳ Mechanism: the assignment record identifies three committed chains;
    the disclosed artifact contains only one.

Read what it refuses on the honest case. Every cryptographic check passes and evidentiary reliance is still not established, because no witness observed the run and nothing outside the record states how many runs the assignment holds.

This block is copied output and can go stale. CI checks it against code/seal/demo_60s.py rather than trusting it.

Verification status

The claims in this repository are asserted by CI on every push rather than described. What currently passes:

The division of labour is deliberate: SMT for mathematical invariants forced by the construction, property-based testing for input-shaped questions quantified over arbitrary values, and unit tests for explicit design rules somebody chose and could have chosen differently. Each spec proves a safety property over unbounded histories and drives the real implementation over concrete traces, because a proof about a model that nothing ties to the code establishes nothing about the code.

What this establishes about the repository is limited to the checks above. The scaffold is not production-ready, no hosted custody service exists, the capture layer does not enforce completeness, and independent audit has not been performed.

Security

The security property this project cares about is narrow: a party should not be able to make an epistemic claim true by declaring it. Vulnerability reporting, in-scope and out-of-scope findings, and the documented known limits are in SECURITY.md.

License

MIT. See LICENSE.

Contact

eli@semafide.com