Topology and dependency authority map for the governed Verifrax system.
- Layer: Governance / topology reference
- Repository class: reference-only
- Package surface: none
- Public host ownership: none
- Governed role: architecture map and repository-boundary reference only
- License: Apache License Version 2.0
ARCHITECTURE defines how the Verifrax repositories, public hosts, authority surfaces, execution surfaces, verification surfaces, and evidence surfaces connect without becoming an authority, runtime, verifier, or public product surface itself.
This repository is the structural map for the Verifrax stack.
It exists to describe:
- repository layer boundaries
- authority flow
- execution flow
- verification flow
- receipt flow
- evidence registration flow
- public-host ownership map
- governed dependency direction
- repository-to-surface alignment requirements
This repository is a reading surface for architecture, not a source of executable truth.
This repository is not:
- the authored protocol source
- the derived specification publication surface
- the authority issuance surface
- the governed execution runtime
- the public verifier surface
- the public proof publication surface
- the public intake surface
- the seal archive surface
- a package distribution surface
- a placeholder quickstart repository
- a generic documentation mirror
It must not contain:
- install placeholders
- fake runnable setup instructions
- speculative deployment claims
- package-install instructions for non-package content
- host claims it does not own
- authority claims it does not hold
Use this wording consistently across architecture material:
- VERIFRAX authors normative source material.
- VERIFRAX-SPEC publishes derived specification artifacts from VERIFRAX.
- Derived artifacts are not upstream authority.
- Governance authority is external and bound through AUCTORISEAL plus the governed repo set in
.github.
ARCHITECTURE documents those relationships. ARCHITECTURE does not create them.
The governed stack is modeled in this order:
.github— organization governance root and governed-repository boundaryAUCTORISEAL— authority issuance and authority reference boundaryCORPIFORM— governed execution and receipt boundaryVERIFRAX— authored protocol, evidence root, and verification boundaryVERIFRAX-SPEC— derived publication of specification artifactsVERIFRAX-PROFILES— deterministic verification-profile corpusVERIFRAX-verify— public verifier surfaceproof— public proof publication surfaceapply— public intake surfaceSIGILLARIUM— seal/archive interface surfacecicullis— enforcement and merge-boundary surface
Lower layers must not be redefined by higher presentation surfaces. Presentation repos must not silently absorb authority or execution roles.
ARCHITECTURE owns no public host.
It must only document this host separation:
api.verifrax.net— execution surfaceproof.verifrax.net— proof publication surfaceauctoriseal.verifrax.net— authority issuance/reference surfacecorpiform.verifrax.net— runtime reference surfacecicullis.verifrax.net— enforcement reference surfaceverify.verifrax.net— verification tooling surfacesigillarium.verifrax.net— seal/archive surfaceapply.verifrax.net— intake surfacewww.verifrax.net— commercial/public primary surfaceverifrax.net— apex redirect only
If any topology document collapses two of those roles into one surface without an explicit governance change, the architecture map is wrong.
Read the system in this order:
.githubfor governed boundary and organizational control surfaceAUCTORISEALfor authority-of-record and authority artifactsCORPIFORMfor governed execution and receipt semanticsVERIFRAXfor authored protocol and evidence rootVERIFRAX-SPECfor derived published specification materialVERIFRAX-PROFILESfor deterministic verification profile constraintsVERIFRAX-verifyfor public verification surface behaviorproof,apply, andSIGILLARIUMfor public-facing bounded surfaces
ARCHITECTURE should be read alongside those repos, not instead of them.
This repository consumes:
- repository role truth from governed repositories
- governance boundaries from
.github - authority boundaries from
AUCTORISEAL - execution boundaries from
CORPIFORM - verification and evidence boundaries from
VERIFRAX - derived-publication boundaries from
VERIFRAX-SPEC - public-surface boundaries from
VERIFRAX-verify,proof,apply, andSIGILLARIUM
This repository produces:
- topology documentation
- stack diagrams
- dependency rules
- architecture constraints
- repository interaction references
It does not produce:
- authority objects
- execution receipts
- verifier verdicts
- evidence artifacts
- public-host deployments
This repository must remain compatible with the authority → execution → verification → evidence-registration path used by artifact-0005 in the VERIFRAX evidence root.
That means topology documents in this repository must preserve, without contradiction:
- public authority issuance through AUCTORISEAL
- governed execution through CORPIFORM
- independent verification through VERIFRAX and maintained verifier surfaces
- evidence registration in VERIFRAX
ARCHITECTURE does not register artifact-0005. ARCHITECTURE must not claim artifact-0005 is complete, sealed, or broader than the evidence root proves.
- Verifrax organization root
.githubAUCTORISEALCORPIFORMVERIFRAXVERIFRAX-SPECVERIFRAX-PROFILESVERIFRAX-verifyproofapplySIGILLARIUMcicullis
Because this repository participates in the governed documentation perimeter, it should expose real repository-identity and determinism checks where governance requires them.
The README must not use badge theater to imply checks that do not exist.
Any CI referenced here must be real, load-bearing, and mechanically verifiable.
The governed Verifrax path that this README must stay compatible with is:
.github— organization governance and governed repository boundaryAUCTORISEAL— authority issuance and public authority referenceCORPIFORM— governed execution and receipt emissionVERIFRAX— authored protocol, evidence root, and artifact-chain registration boundaryVERIFRAX-SPEC— derived specification publication surfaceVERIFRAX-PROFILES— deterministic profile-constraint surfaceVERIFRAX-SAMPLES— pinned sample and reproducibility surfaceVERIFRAX-verify— public verification repository and UI boundaryVERIFRAX-DOCS— explanatory documentation surfacecicullis— enforcement boundaryproof— proof publication surfaceSIGILLARIUM— seal and archive reference surfaceapply— intake surface
The live host-label map that must remain explicit and non-contradictory is:
https://api.verifrax.net/— execution surfacehttps://proof.verifrax.net/— proof publication surfacehttps://auctoriseal.verifrax.net/— authority issuance and authority reference surfacehttps://corpiform.verifrax.net/— runtime and receipt reference surfacehttps://cicullis.verifrax.net/— enforcement reference surfacehttps://verify.verifrax.net/— public verification surfacehttps://sigillarium.verifrax.net/— seal and archive reference surfacehttps://apply.verifrax.net/— intake surfacehttps://docs.verifrax.net/— documentation surface
This README must remain compatible with artifact-0005 as the load-bearing authority → execution → verification → evidence boundary without claiming that this repository alone authors, proves, seals, or registers artifact-0005 unless that role is actually true for this repository.
Use the repository security policy for disclosure handling.
Architecture documents must not publish sensitive operational details, hidden credentials, emergency-only procedures, or private infrastructure secrets.
Changes to this repository change how the system is interpreted.
Accepted changes must therefore:
- preserve authority direction
- preserve host separation
- preserve repository role boundaries
- avoid speculative current-state claims
- stay aligned with governed repository truth
If a change would make a reader misidentify who owns authority, execution, verification, or public host control, the change is wrong.
Apache License Version 2.0. See LICENSE.