{ "schema_version": "claim-ledger.v1", "published_at": "/claim-ledger.json", "purpose": "Every load-bearing public claim carried on the published routes, the evidence class that supports it, and the exact wording published. A claim with no live evidence is either described as architecture, marked future-facing, or removed. Each published_wording is a verbatim quote of text rendered on at least one route named beside it, and CI fails if it is not. This file is the human-readable companion to the machine guard in claims_test.go; the guard forbids asserting terms this ledger does not support, and it reads the rendered pages rather than the source tree, so wording introduced in Go code is covered too.", "reading_rules": [ "VERIFIED means a live artefact or register entry supports the claim today.", "ARCHITECTURAL_DESCRIPTION means the wording describes how the system is built, and must never be read as a statement about production availability.", "FUTURE_FACING means the wording describes an intent, and must be phrased so that no reader could take it for a present state.", "REMOVE means the claim was withdrawn from the public sites and may not return until its evidence exists.", "published_wording is quoted verbatim from the rendered page, markup and character entities aside. If a page changes, this file fails CI until it is requoted." ], "claims": [ { "claim": "ProvableCORE produces signed, content-bound records for governed events.", "evidence": "Receipt artefacts exist and their signature and content binding are reproducible from the recorded digest. The receipts produced to date were generated by controlled test invocations, so this supports the mechanism only.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/", "/what-it-is", "/how-it-works", "/governance-receipts" ], "published_wording": "ProvableCORE is the proof layer for governed AI and digital operations: signed, content-bound, independently verifiable records for decisions made by AI and automated systems." }, { "claim": "A record can be verified independently of the party that produced it.", "evidence": "The verification procedure and record format are specified, and a receipt can be checked offline from its own content. The public verification endpoint is out of service and no authenticated verification service is offered in its place, so the published wording describes the property of the record and never an available service.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/for-auditors", "/technical-resources", "/governance-receipts" ], "published_wording": "Independently verifiable, content-bound records with authority context, designed to support evidence gathering, control mapping, and replay." }, { "claim": "The sites do not claim that signing keys are held in a hardware security module.", "evidence": "No such protection level is proven for any production key on this estate; signing does not use hardware-backed key protection, and the site therefore states the managed-key model instead.", "status": "REMOVE", "routes": [], "published_wording": "" }, { "claim": "Authoritative signing is controlled and fail-closed.", "evidence": "The signing path refuses to issue when its authority context is absent or expired; that behaviour is exercised by the test suite of the signing service rather than by a public artefact.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/security", "/trust-model" ], "published_wording": "The ProvableCORE security model: controlled authoritative signing, fail-closed behaviour, and responsible disclosure." }, { "claim": "Preserved records are retained under a write-once retention policy.", "evidence": "The preservation bucket carries a locked retention policy with object versioning, which is readable from bucket metadata. Retention is a deployment configuration, so the wording never asserts that a record cannot be altered by anyone.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/security", "/how-it-works", "/technical-resources" ], "published_wording": "Signed, content-bound proofs are preserved as durable evidence records. The locked-retention trust tier describes proofs held under a locked-retention regime for a defined preservation window when configured; it is not a claim that every record is kept for an unlimited time or is impossible to remove." }, { "claim": "ProvableCORE holds a registered trademark in Moldova.", "evidence": "AGEPI registration number 7671 is a granted Moldovan registration. The United States filing is pending before the USPTO and is published as pending, never as granted. The registered symbol is therefore used only on the European edition, where the Moldovan registration supports it; the global edition, whose readers would read the symbol against a United States register, uses the unregistered mark symbol and names the register explicitly.", "status": "VERIFIED", "routes": [ "/", "/what-it-is", "/how-it-works", "/governance-receipts", "/trust-model", "/use-cases", "/for-auditors", "/technical-resources", "/security", "/pricing", "/request-access", "/intellectual-property", "/privacy", "/terms" ], "published_wording": "ProvableCORE® — registered in Moldova (AGEPI Nr. 7671). USPTO filing pending." }, { "claim": "The sites do not claim any patent or patent-pending status for ProvableCORE.", "evidence": "ProvableCORE does not hold a granted patent, and it does not have a patent application pending. The intellectual-property route asserted a pending filing in its meta description, and therefore in its search result and its social card, with nothing behind it. That description does not name such a filing any more, and this entry exists so that it cannot return without one.", "status": "REMOVE", "routes": [], "published_wording": "" }, { "claim": "The sites do not claim that ProvableCORE is certified, approved or endorsed by a regulator.", "evidence": "No certification, approval or endorsement exists. The sites carry the opposite statement explicitly so the absence is published rather than merely unstated.", "status": "REMOVE", "routes": [], "published_wording": "" }, { "claim": "ProvableCORE supports evidence and record-keeping expectations in regulated environments.", "evidence": "Control mapping and audit-support material exist as documentation. Support is described strictly as support, and the accompanying note withdraws any reading as conformity or endorsement.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/", "/for-auditors", "/use-cases" ], "published_wording": "Where specific European frameworks are named, ProvableCORE is described strictly as designed to support their evidence and record-keeping expectations, and to provide control mapping and audit support. It is not a certification of, and does not assert conformity with or endorsement by, any regulator." }, { "claim": "The sites do not claim that ProvableCORE guarantees the customer's regulatory compliance.", "evidence": "A vendor cannot guarantee a customer's compliance, and no evidence class could establish it. The published wording states the limit instead.", "status": "REMOVE", "routes": [], "published_wording": "" }, { "claim": "The sites do not claim that any named institution uses ProvableCORE.", "evidence": "No production workload has been recorded. Every receipt produced to date came from a controlled test invocation, so no adoption, customer or volume claim is supportable.", "status": "REMOVE", "routes": [], "published_wording": "" }, { "claim": "The listed prices are the operator's current commercial terms, and are not a binding offer.", "evidence": "The figures are the operator's own statement, and this entry previously cited the pricing page as the evidence for the pricing page. No transaction, agreement or invoice at these prices is cited here, and none is evidenced anywhere this ledger can point to. What is checkable is the limit the site places on the figures: the pricing route states that they are commercial terms only and not a binding purchase agreement, and the terms route states that the content of this site does not constitute a binding offer. This entry records that disclaimed form, and the earlier reading as an offer contradicted the terms route. It is FUTURE_FACING because a price that is not a binding offer states terms the operator would contract on, and not a transaction that has taken place.", "status": "FUTURE_FACING", "routes": [ "/pricing" ], "published_wording": "Pricing is shown as current commercial terms only. It excludes service-level, performance, and availability figures, and it is not a binding purchase agreement." }, { "claim": "Access is obtained through a controlled onboarding conversation rather than by self-service purchase.", "evidence": "The request-access form posts to an intake endpoint and issues nothing: no account, no credential, no key. That is readable from the shipped form and is asserted by the test suite.", "status": "VERIFIED", "routes": [ "/request-access", "/pricing" ], "published_wording": "Request institutional access to ProvableCORE. Submitting the form starts a conversation; it does not create an account or issue credentials." }, { "claim": "The plan volume tiers describe capacity the platform is intended to serve.", "evidence": "The receipt counts are plan limits set by the operator, not measured throughput. No production workload has been recorded, so no volume, throughput, capacity or concurrency figure is observed and none may be read into the plan limits.", "status": "FUTURE_FACING", "routes": [ "/pricing" ], "published_wording": "up to 10,000 receipts / month" }, { "claim": "The governed sequence behind a record can be replayed.", "evidence": "The replay procedure is specified against the recorded proof structure. It is described as a property of the record format, and no service-level availability is asserted for it.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/for-auditors", "/technical-resources" ], "published_wording": "A record carries the proof structure, authoritative signature, content binding and authority context required to check its proof and replay its governed sequence. No verification service is currently offered, public or authenticated; verifiability is a property of the record itself." }, { "claim": "A preserved record can belong to a structure whose internal consistency is checkable cryptographically (trust tier 2).", "evidence": "Consistency structures are constructed over preserved records by the platform, and the property is a property of the record structure. No production workload has been recorded, so no consistency proof over production data exists to cite.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/trust-model", "/" ], "published_wording": "The record is part of a structure whose internal consistency can be checked cryptographically." }, { "claim": "A signed content-bound proof can be anchored to an authoritative reference point (trust tier 4).", "evidence": "Anchoring is a tier the platform is designed to provide when configured. No anchor artefact for a production workload exists, because no production workload has been recorded, so the tier is published as a capability of the model and not as a property every record carries.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/trust-model", "/" ], "published_wording": "The signed content-bound proof is anchored to an authoritative reference point." }, { "claim": "A governed event becomes a verifiable record through the published six-step process.", "evidence": "The six steps describe the implemented processing path. Every receipt produced to date came from a controlled test invocation, so the sequence is evidenced as a mechanism and not as a production process running under load.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/how-it-works", "/" ], "published_wording": "The six-step ProvableCORE proof process, from governed event and content binding through authoritative signing, preservation, verification, and replay." }, { "claim": "A governance receipt records the eight fields of the published receipt anatomy.", "evidence": "The eight fields are the fields the record format defines. The example rendered beside them is labelled synthetic and carries no production identifier, because no production receipt may be shown.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/governance-receipts", "/how-it-works" ], "published_wording": "A governance receipt is the evidence record produced for a governed event. It records, at minimum, the fields below." }, { "claim": "Personal data submitted through the request-access form is handled on a basis stated by the operator.", "evidence": "The basis published on the privacy route is the visitor's own request and consent, stated by the operator of record. No jurisdiction, statutory basis or external attestation is named, and none may be inferred from the notice; this is a description of the operator's practice and not a verified legal position, so it is not carried as VERIFIED.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/privacy" ], "published_wording": "Data is processed by TF Holding S.R.L. on the basis of your request and consent. Processing is designed to support applicable data-protection accountability expectations; this notice is not a legal-compliance certification." }, { "claim": "A record carries what is needed to check its proof and replay its governed sequence.", "evidence": "The check and the replay are defined against the recorded proof structure, signature, content binding and authority context, so both are properties of the record format. No verification service is offered, public or authenticated, and the public verification endpoint is out of service, so nothing in this wording describes a service a reader could reach. The step used to end by saying that what happened could be re-examined by any party holding the record; no verification specification and no signing key are published anywhere a reader could obtain them, so nothing supports a statement about what a holder is able to do, and the sentence now ends at the contents of the record. The receipts produced to date came from controlled test invocations.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/", "/how-it-works" ], "published_wording": "The record carries what is needed to check its proof and replay its governed sequence." }, { "claim": "Every sector card on the use-cases route describes one mechanism applied to a different kind of decision.", "evidence": "The lede states the pattern the sector cards share, and each card restates it for one sector. No named institution in any of these sectors uses ProvableCORE, no sector deployment exists, and every receipt produced to date came from a controlled test invocation, so a card may name a kind of event and the record made of it, and may never name a customer, a deployment or an outcome. The closing sentence of the lede withdraws any reading as legal compliance. This entry asserts a property of every card while quoting only the lede, so it is checkable only because each card now carries its own entry below; CI fails if a rendered card is quoted by none of them.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/use-cases" ], "published_wording": "In every sector the pattern is the same: a governed event is captured, its content is bound, and a signed record enables verification and replay for evidence and audit support. No sector claim asserts legal compliance." }, { "claim": "The agriculture and supply chain card names traceability events and the evidence records made of them.", "evidence": "No agricultural or supply-chain operator uses ProvableCORE and no traceability event has been recorded outside controlled test invocations. Due-diligence requirements are named as something the record is framed to support, never as a requirement the record satisfies.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/use-cases" ], "published_wording": "Traceability events across agriculture and supply chains are preserved as evidence records, framed as evidence support for due-diligence requirements." }, { "claim": "The banking and credit card names credit and underwriting decisions as governed events and the record made of them.", "evidence": "No bank or credit institution uses ProvableCORE, and no credit decision has been recorded for one: no production workload exists, and every receipt produced to date came from a controlled test invocation. The card names a kind of decision and the record produced for it, and names no institution, no deployment and no outcome. Credit governance and audit evidence are named as things the record supports.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/use-cases" ], "published_wording": "Credit, underwriting, and model-driven decisions become governed events; a content-bound signed record supports credit-governance and audit evidence." }, { "claim": "The insurance card names pricing, claims and automated underwriting actions as governed events recorded with authority context.", "evidence": "No insurer uses ProvableCORE and no insurance workload has been recorded. The card names the actions and the record made of them, and names no insurer, no deployment and no outcome; audit support is named as support only.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/use-cases" ], "published_wording": "Pricing, claims, and automated underwriting actions are recorded as governed events with authority context for audit support." }, { "claim": "The public administration card names automated eligibility, allocation and case decisions as governed events captured as verifiable records.", "evidence": "No public body uses ProvableCORE and no administrative decision has been recorded for one. Administrative accountability is named as what the record is meant to support; no authority has reviewed, approved or endorsed ProvableCORE, and the card names none as doing so.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/use-cases" ], "published_wording": "Automated eligibility, allocation, and case decisions are captured as verifiable records to support administrative accountability." }, { "claim": "The enterprise AI agents card names agent actions as content-bound signed records that can be examined.", "evidence": "No enterprise AI deployment of ProvableCORE exists, and no agent action has been recorded outside controlled test invocations. Examination is named as a property of the record; no verification service is offered, public or authenticated, and the public verification endpoint is out of service.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/use-cases" ], "published_wording": "Actions taken by enterprise AI agents are bound to their content and signed, so what an agent did and under whose authority can be examined." }, { "claim": "The healthcare governance card names governed decisions in healthcare operations as records carrying content binding and authority context.", "evidence": "No hospital, clinic or health authority uses ProvableCORE, and no healthcare decision has been recorded. The card names the decision and the record made of it; it names no institution, no deployment, no patient outcome and no clinical result. Governance review is named as what the record is meant to support.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/use-cases" ], "published_wording": "Governed decisions in healthcare operations are recorded with content binding and authority context to support governance review." }, { "claim": "The legal and audit card names governed events in legal and audit workflows as independently verifiable, replayable records.", "evidence": "No legal or audit practice uses ProvableCORE and no legal or audit workflow has been recorded. Verifiability and replay are defined against the recorded proof structure and are named as properties of the record format; no verification service is offered, public or authenticated.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/use-cases" ], "published_wording": "Governed events across legal and audit workflows become independently verifiable, replayable records for evidence support." }, { "claim": "Access is governed by separate agreements entered into at onboarding, and not by this website.", "evidence": "This is a term stated by the operator, not an observed fact, and it is recorded here as one. What the site itself demonstrates is the negative half of it: the request-access form posts to an intake endpoint and issues no account, no credential and no key, which is readable from the shipped form and asserted by the test suite. No such agreement is published or cited here, and none is evidenced in this ledger; the same route states that the content of this site does not constitute a binding offer.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/terms" ], "published_wording": "Access to ProvableCORE is granted through a controlled onboarding process and is governed by separate agreements entered into at onboarding." }, { "claim": "A request to see, correct or delete the personal data submitted through the form is handled by the operator at the published address.", "evidence": "The route publishes a contact address for those requests and names the operator of record. Handling is an operator practice: the page names no statutory right, no jurisdiction, no supervisory authority and no response deadline, none is implied here, and no external attestation supports it. The only basis the site states for holding the data is the visitor's own request and consent.", "status": "ARCHITECTURAL_DESCRIPTION", "routes": [ "/privacy" ], "published_wording": "To ask what we hold about you, to correct it, or to have it deleted, contact contact@agrocapitalstandard.eu" } ] }