Veröffentlichung und Discovery

Eine Maschine sollte die Repräsentation finden, bevor sie zu raten beginnt.

Ein ESFI-Standard wird als Vertrag veröffentlicht, den Menschen lesen und Implementierungen erzeugen können. Die Spezifikation ist die maßgebliche Beschreibung dieses Vertrags; die maschinenlesbaren Artefakte zeigen ihn in Anwendung. Diese Seite beschreibt, was ein MPF-Publisher online stellt, wie eine Maschine es findet und was jeder Mechanismus feststellt und was nicht.

Jeder Mechanismus ist als Spezifikation 0.7, Referenzimplementierung oder ESFI-Praxis gekennzeichnet. Die Marker werden im Überblick erklärt.

Was ein Publisher online stellt

Artefakt	Publikum	Rolle	Status
Spezifikationsseite	Menschen, Implementierer	Der veröffentlichte Vertrag für eine Formatversion	Spezifikation 0.7
Seiten-`.mpf`-Datei	Maschinen	Maschinenrepräsentation einer menschlichen Seite	Spezifikation 0.7
`llms.mpf`	Maschinen	MPF-Index aller indexierten Seiten der Site	Spezifikation 0.7
`llms.txt`	Maschinen, Menschen	Leichtgewichtiger Einstiegspunkt mit MPF-Abschnitt	Spezifikation 0.7
`llms-full.txt`	Maschinen	Bodies indexierter Seiten in der Standardsprache, verkettet	Spezifikation 0.7
`.sig`-Dateien	Maschinen	Signaturen von MPF-Dateien, wenn der Publisher signiert	Spezifikation 0.7
`/.well-known/mpf`	Maschinen	MPF-Deklaration auf Site-Ebene über HTTPS	ESFI-Praxis
DNS TXT `_mpf.<domain>`	Maschinen	MPF-Deklaration auf Site-Ebene vor jedem HTTP-Request	ESFI-Praxis
`<link rel="alternate">`	Maschinen	Seitenweiser Zeiger von HTML auf den Companion	ESFI-Praxis

Wie eine Maschine MPF findet

Die Mechanismen sind vom billigsten Signal bis zum spezifischsten geschichtet. Ein Leser kann bei jedem beginnen; sie sind so entworfen, dass sie übereinstimmen.

1. DNS TXT — vor dem ersten Request

ESFI-Praxis

Ein Leser kann mit einer DNS-Abfrage erfahren, dass eine Domain MPF veröffentlicht, wo ihr Index liegt und welchen Site-weiten Scope sie hat:

_mpf.example.org  TXT  "v=0.7;index=https://example.org/llms.mpf;scope=cite:1,summarize:1,train:0,index:1,relay:0;contact=mailto:web@example.org"

Parameter	Bedeutung
`v`	MPF-Version
`index`	Absolute URL von `llms.mpf`
`scope`	Site-weite Standard-`companion-scope` als `flag:1` oder `flag:0`
`contact`	Kontakt für Maschinenleser

Der Eintrag ist kurz genug für eine einzelne DNS-Antwort. Der Builder erzeugt ihn nicht; der Publisher fügt ihn zur Zone hinzu.

2. `/.well-known/mpf` — dieselbe Deklaration über HTTPS

ESFI-Praxis

Derselbe String, als Klartext ausgeliefert:

GET /.well-known/mpf
v=0.7;index=https://example.org/llms.mpf;scope=cite:1,summarize:1,train:0,index:1,relay:0;contact=mailto:web@example.org

Liefern Sie ihn als statische Datei aus (zum Beispiel in public/.well-known/mpf) und stellen Sie sicher, dass der Server ihn als text/plain zurückgibt. Der Builder erzeugt ihn nicht. mpf ist noch keine registrierte well-known URI; ESFI verwendet den Pfad als Konvention.

3. `llms.txt` — der konventionelle Einstiegspunkt

Spezifikation 0.7

Der Builder erzeugt llms.txt, wenn es nicht existiert, oder ersetzt seinen MPF-Abschnitt und bewahrt alles andere. Der Abschnitt enthält immer:

MPF: 0.7
MPF-spec: https://docs.esfi.eu/spec/mpf/0.7
MPF-index: /llms.mpf

## Pages
- [Page title](https://example.org/page/index.mpf): summary

MPF-spec erscheint, wenn spec-url konfiguriert ist, und ermöglicht einem Leser, die kanonische Spezifikation der deklarierten Version ohne Raten zu erreichen. Der einleitende Satz, den der Builder darüber schreibt, ist Wortlaut der Referenzimplementierung.

4. `llms.mpf` — der Site-Index

Spezifikation 0.7

llms.mpf ist selbst ein MPF-Dokument. Sein Body listet jede Seite mit index: true, sortiert nach MPF-URL, jeweils mit Summary, sofern vorhanden. Sein Frontmatter deklariert eine feste Identität (<prefix>:page:llms), content-type: reference und verborgene Nicht-HTML-Parität, weil keine menschliche Seite dahintersteht.

5. Die Seite selbst

Spezifikation 0.7 für Pfad und mpf-url; ESFI-Praxis für den Alternate Link.

Jede Seite trägt ihren Companion am selben Pfad, mit .mpf anstelle von .html:

/about/index.html   →   /about/index.mpf

Jede MPF-Datei adressiert sich selbst über mpf-url und zeigt über url zurück auf ihre menschliche Seite.

Eine HTML-Seite kann aus ihrem <head> ebenfalls auf den Companion zeigen:

<link rel="alternate" type="text/mpf" href="/about/index.mpf" title="Machine Page Format">

text/mpf ist kein registrierter Medientyp; ESFI verwendet ihn als Konvention, damit Leser den Link erkennen können. Der Builder fügt ihn nicht hinzu; das Site-Template tut es.

Wenn Site und Seite widersprechen

DNS-Eintrag und /.well-known/mpf geben Site-weite Defaults an. Das Frontmatter einer Seite sagt, was für diese Seite gilt, einschließlich jedes Seiten-Overrides. ESFI-Praxis: Auf ESFI-Sites geben alle drei dieselben Site-weiten Werte an, und ein Leser sollte das Seiten-Frontmatter als Deklaration für diese Seite behandeln. Wenn eine Site-weite Deklaration und eine Seite ohne erklärendes Override widersprechen, ist das ein Veröffentlichungsfehler, kein Signal, zwischen ihnen zu wählen.

Menschenkanon und Maschinen-Companion

Die menschliche Seite und ihre MPF-Datei sind zwei Repräsentationen verwandten Inhalts, keine austauschbaren Autoritäten.

url identifiziert die kanonische menschliche Seite.
mpf-url identifiziert die Maschinenrepräsentation.
content-parity deklariert, wie beide zueinander stehen.
source-hash identifiziert das exakte HTML, aus dem die MPF-Datei erzeugt wurde.
mpf-id identifiziert die erzeugte MPF-Datei selbst.

Diese Trennung erlaubt einer Maschine, die Maschinenrepräsentation zu zitieren oder zu verarbeiten, ohne die Adresse der menschlichen Quelle zu verlieren. Für Übersetzungen listet language-variants die erwarteten MPF-Adressen desselben logischen Inhalts in anderen konfigurierten Sprachen; der Builder erzeugt diese Adressen und prüft nicht, ob die Dateien existieren.

Offenes Format, ESFI-Referenzpraxis

MPF ist ein offenes Format. Jeder kann konformes MPF erzeugen und konsumieren, ohne irgendwo gelistet zu sein, ohne Registrierung und ohne einen ESFI-Dienst zu verwenden.

ESFIs eigene Sites sind eine inspizierbare Referenzpraxis: Sie emittieren MPF, veröffentlichen die Site-Indizes und die Practice-Level-Discovery-Deklarationen und stellen alles zur Prüfung gegen die Spezifikation bereit. Das Implementierungsregister dokumentiert Emitter, deren Ausgabe verifiziert wurde. Es ist Evidenz einer Implementierung, keine Erlaubnis zu implementieren.

Spezifikation, Implementierung und Praxis

Die Spezifikation ist der kanonische, menschenlesbare Vertrag einer veröffentlichten Version. Eine veröffentlichte Version bleibt erreichbar; Korrekturen, die den Vertrag nicht verändern, werden nach der Richtlinie für Versionierung behandelt.
Die Referenzimplementierung macht aus der Spezifikation beobachtbare Ausgabe. Sie ist keine zweite Spezifikation. Wenn Prosa und Implementierung bei einer veröffentlichten Version abweichen, werden sie wieder in Einklang gebracht; Leser sollen keinen dritten Vertrag aus Beispielen ableiten müssen.
Praxis ist, wie ESFI MPF über das hinaus deployt, was der Builder erzeugt. Sie wird dokumentiert, damit andere sie reproduzieren können. Sie wird nur durch eine neue Spezifikationsversion Teil des Vertrags.

Ein Draft, Vorschlag oder geplanter Mechanismus gehört erst zu diesen Konventionen, wenn er veröffentlicht und verifizierbar ist.

Was Veröffentlichung nicht impliziert

Die Veröffentlichung eines Feldes oder einer Deklaration erzeugt keinen Dienst dahinter. Provenienz, Confidence, Scope und Language Variants sind beschreibend, sofern die Spezifikation kein weiteres Verhalten definiert. Discovery-Mechanismen helfen einem Leser, die Deklarationen des Publishers zu finden; sie machen diese Deklarationen nicht wahr, bindend oder durchgesetzt.

Die Spezifikation definiert den Vertrag; die Referenzimplementierung demonstriert ihn; Praxis erweitert, wie er gefunden wird; veröffentlichte Artefakte machen alle drei inspizierbar.