Proofscaling

For fund managers and thesis builders

Extend the Standard for your domain.

schema.org gives the web a base type for a recipe, a product, an event. Publishers extend those types for their own needs without breaking the shared vocabulary. A Domain Thesis does the same for proof. You specialize the base types for your domain. You do not fork them.

The extension rule

A Domain Thesis may add proofs and may narrow reporting within a base type. It may never alter, remove, or redefine a base type. A change to a base type ships only by versioned amendment to the Standard, never by per-thesis exception.

May add

A Domain Thesis may add proofs within a base type. New evidence your domain cares about, on the same cadence.

May narrow

A Domain Thesis may narrow reporting within a base type. Tighten a unit, fix a cadence, require a field. Narrow, never loosen.

May never alter

A Domain Thesis may never alter, remove, or redefine a base type. A change to a base type ships only by versioned amendment to the Standard.

Conformance

Theses conform. Nobody is certified.

A Domain Thesis conforms to the Proofscaling Standard when it follows the extension rule and is pinned by content hash. Conformance is a property of the document, checkable by anyone holding it against the published schema. It is not a credential, and it is not conferred.

Proofscaling does not certify, endorse, select by invitation, or accept payment from any issuer. Issuers appear on the Screen from the public record alone. The nearest analogy is the one this page already uses: schema.org reviews and hosts extensions to a shared vocabulary. It does not certify the websites that use them.

How to write a Domain Thesis

Five steps, then pin it.

  1. 01

    Choose the base types you report.

    Pick from the five Proof Dimensions. Report the ones your domain proves on.

  2. 02

    Add the proofs your domain needs.

    Extend within a base type. Name each added proof and say what it reports.

  3. 03

    Narrow where your domain is stricter.

    Fix units, cadences, and required fields. A narrowing tightens the base type for your readers.

  4. 04

    Declare your Thesis Scope.

    Direct is one operating thesis. Diversified is a portfolio of theses. State which you are.

  5. 05

    Pin it by content hash.

    Publish the document and pin it. A Pinned Thesis is adopted by consent, one hash agreed by both sides.

Thesis Scope

Direct or diversified.

Thesis Scope extends existing fund thesis vernacular. A direct thesis proves one operating case. A diversified thesis proves a portfolio, many cases under one steward. Both use the same base types. The scope tells a reader what the thesis is accountable for.

direct

One operating thesis. One case to prove, reported on the Proof Cycle.

diversified

A portfolio of theses under one steward, aggregated on the same cadence.

A worked example

A bond thesis, extended.

A diversified thesis for a bond architecture. It extends Playbook with added proofs for a yield pathway and a reserve, extends Form with a base for a tax-equity pathway, and narrows the Playbook unit of account and liquidity cadence. It adds. It narrows. It alters nothing.

Domain Thesis, example instancequantinuity-bond.thesis.json
{
  "thesisId": "quantinuity.bond",
  "name": "Quantinuity Bond Thesis",
  "author": "Quantinuity",
  "standardVersion": "0.2",
  "thesisScope": "diversified",
  "extends": [
    "playbook",
    "form",
    "stats"
  ],
  "addedProofs": [
    {
      "dimension": "playbook",
      "key": "revBondSeries",
      "description": "Outstanding REV Bonds by series. Yield pathway, 1099-INT bearing."
    },
    {
      "dimension": "playbook",
      "key": "exchangeReserveCoverage",
      "description": "Coverage of REV Notes by the Exchange Reserve."
    },
    {
      "dimension": "form",
      "key": "revShareBase",
      "description": "REV Share base for the tax-equity pathway, K-1 bearing."
    }
  ],
  "narrowings": [
    {
      "dimension": "playbook",
      "constraint": "unitOfAccount is REV at every layer."
    },
    {
      "dimension": "playbook",
      "constraint": "liquidityCadence is March 20, June 20, September 20, December 20."
    }
  ],
  "pinned": "sha256:774711ce81203fe6f6305a92c49c7bbd58895b9e8572b411e5148bbde2ce43a2"
}

The schema

Domain Thesis, version 0.2.

The stub for a Domain Thesis document. Pin the document by content hash to make it a Pinned Thesis, so both sides read the same shapes for the term of the agreement.

Domain Thesis schemadomain-thesis.schema.json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://proofscaling.org/schema/0.2/domain-thesis.schema.json",
  "title": "Domain Thesis",
  "description": "A fund manager's specialization of the base types for a domain, the way a publisher extends a schema.org type. A Domain Thesis may add proofs and narrow reporting. It may never alter a base type.",
  "$comment": "Stub for Proofscaling 0.2. A Pinned Thesis is this document at a specific version, identified by content hash. The dimension enum is defined once, in proof-record, and referenced here so the list cannot drift.",
  "type": "object",
  "properties": {
    "thesisId": {
      "type": "string"
    },
    "name": {
      "type": "string"
    },
    "author": {
      "type": "string"
    },
    "standardVersion": {
      "const": "0.2"
    },
    "thesisScope": {
      "description": "The scope of the thesis. Direct is one operating thesis. Diversified is a portfolio of theses.",
      "enum": [
        "direct",
        "diversified"
      ]
    },
    "extends": {
      "description": "The base Proof Dimensions this thesis reports and specializes.",
      "type": "array",
      "items": {
        "$ref": "proof-record.schema.json#/properties/dimension"
      },
      "minItems": 1
    },
    "addedProofs": {
      "description": "Proofs this thesis adds within a base type. Permitted by the extension rule.",
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "dimension": {
            "$ref": "proof-record.schema.json#/properties/dimension"
          },
          "key": {
            "type": "string"
          },
          "description": {
            "type": "string"
          }
        },
        "required": [
          "dimension",
          "key"
        ],
        "additionalProperties": false
      }
    },
    "narrowings": {
      "description": "Reporting this thesis narrows within a base type. Permitted by the extension rule. A narrowing may tighten, never loosen.",
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "dimension": {
            "$ref": "proof-record.schema.json#/properties/dimension"
          },
          "constraint": {
            "type": "string"
          }
        },
        "required": [
          "dimension",
          "constraint"
        ],
        "additionalProperties": false
      }
    },
    "pinned": {
      "description": "The content hash that pins this thesis. Adopted by consent.",
      "type": "string",
      "pattern": "^sha256:[0-9a-fA-F]{64}$"
    }
  },
  "required": [
    "thesisId",
    "name",
    "standardVersion",
    "thesisScope",
    "extends",
    "pinned"
  ],
  "additionalProperties": false
}

Future integration

Consumers of the Standard.

Proofscaling is a vocabulary. Tools read it. Effect Cause is one such tool in development, a causal inference utility applied to Stats and Conversion. It would consume Proofscaling records rather than define them. It is an example of what reads the Standard, not part of the standard.