Canonical intake repository for https://apply.verifrax.net/, responsible only for applicant intake, intake routing, submission structure, and intake-surface presentation, while remaining outside authority issuance, governed execution, proof publication, public verification, archive publication, documentation authority, status reporting, and evidence-root artifact registration.
- Repository role: intake surface only
- Public host ownership:
https://apply.verifrax.net/ - Surface class: intake and submission boundary
- Deployment model: static or intake-owned deployment only
- Stack position: intake edge adjacent to public-facing Verifrax surfaces
- Authority relation: no authority issuance
- Execution relation: no governed runtime execution
- Proof relation: no proof publication
- Verification relation: no verifier ownership
- Artifact relation: must stay aligned with the artifact-0005 perimeter without claiming authorship, execution, verification, or registration of artifact-0005
- License: Apache License Version 2.0
apply is the Verifrax intake repository and sole owner of apply.verifrax.net, giving the public system one bounded applicant-entry surface without turning intake into execution, proof, authority, verification, archive, or evidence-root behavior.
This repository is the intake boundary.
It exists for:
- applicant-facing intake entry
- structured submission capture
- bounded intake flow
- applicant confirmation surfaces
- intake challenge or task surfaces when intentionally present
- intake-specific UX and copy
- role separation between contribution funnel and protocol/runtime surfaces
A reader should be able to determine immediately:
- where applications are supposed to begin
- what intake owns
- what intake explicitly does not own
- which neighboring surfaces handle execution, proof, authority, and verification instead
This repository is not:
- the commercial primary landing surface
- the execution API
- the authority issuer
- the governed runtime
- the proof publication surface
- the public verifier surface
- the seal archive
- the canonical documentation surface
- the status surface
- the evidence-root artifact registry
Specifically, this repository must not act as:
https://api.verifrax.net/https://proof.verifrax.net/https://auctoriseal.verifrax.net/https://corpiform.verifrax.net/https://verify.verifrax.net/https://sigillarium.verifrax.net/https://docs.verifrax.net/https://status.verifrax.net/https://www.verifrax.net/
It must not publish:
- proof artifacts
- runtime receipts
- authority objects
- archive catalogs
- verifier semantics as the verifier of record
- artifact-0005 registration as the evidence root of record
The limiting case is simple:
If apply can also execute, publish proof, or issue authority, then role separation is gone and the subdomain map is cosmetic only.
So this repository must stay narrow.
The stack needs one public place where applications start.
Without a dedicated intake boundary, the system collapses into cross-surface noise:
- proof becomes intake by accident
- verifier becomes intake by confusion
- docs become intake by fallback
- execution becomes intake by misuse
That is exactly what this repository prevents.
apply gives the system one explicit answer to the question:
Where does applicant submission begin?
Answer:
https://apply.verifrax.net/
Not api.
Not proof.
Not verify.
Not auctoriseal.
Not corpiform.
Not sigillarium.
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.
This repository owns:
https://apply.verifrax.net/
That host should remain intake-only.
It may contain bounded paths such as:
//submit/task/confirm
if those paths are actually implemented and remain intake-only.
It must not become a generic mirror of another surface.
The intake surface is responsible for applicant-facing entry and structured signal capture.
That includes material such as:
- intake forms
- structured submission prompts
- applicant tasks or challenge surfaces
- confirmation states
- intake explanations
- bounded applicant instructions
It does not include:
- public proof retrieval
- governed execution endpoints
- authority object issuance
- receipt publication
- verifier-grade proof checking
- seal archive browsing
- general documentation hosting
The repository-to-surface split is:
.github— organization governance perimeterVERIFRAX— authored source and evidence-root chain contextAUCTORISEAL— authority issuance and authority referenceCORPIFORM— governed execution and receipt boundaryVERIFRAX-SPEC— derived specification publicationVERIFRAX-verify— public verifier surfaceproof— public proof publicationSIGILLARIUM— archive and seal referenceVERIFRAX-DOCS— documentation surfaceapply— intake surface
The correct reading is not “all public sites do everything.” It is “each public site has one bounded role.”
apply is the intake role.
This repository must stay aligned with the artifact-0005 perimeter because public-facing role drift weakens chain trust.
But the boundary is strict.
apply does not:
- author artifact-0005
- issue the artifact-0005 authority object
- execute the artifact-0005 governed runtime path
- verify artifact-0005 as the verifier of record
- register artifact-0005 in the evidence root
What it can do is link outward correctly to the system that does.
That means this repository may reference the neighboring verification and evidence surfaces while staying clear that intake is not the artifact boundary of record.
Verification belongs to:
- repository:
VERIFRAX-verify - public verifier host:
https://verify.verifrax.net/
Proof publication belongs to:
- repository:
proof - public proof host:
https://proof.verifrax.net/
A useful counterexample:
If an applicant can submit through apply, that does not mean apply verifies anything.
If a submission exists, that does not make it proof.
If a form is valid, that does not make it an authority object.
Intake validity is not proof validity.
Authority belongs to:
- repository:
AUCTORISEAL - host:
https://auctoriseal.verifrax.net/
Governed execution belongs to:
- repository:
CORPIFORM - execution host:
https://api.verifrax.net/ - runtime reference host:
https://corpiform.verifrax.net/
This repository must not imply that applicant submission creates authority or triggers governed execution by itself.
This repository accepts applicant-facing input only, such as:
- form submissions
- structured answers
- applicant metadata where intentionally requested
- task responses where intentionally requested
This repository emits intake outputs only, such as:
- submission acknowledgements
- bounded applicant feedback
- confirmation surfaces
- intake-state transitions
It does not emit:
- authority objects
- runtime receipts
- proof artifacts
- verifier verdicts
- archive records
- evidence-root artifact registration
A reader should land here to answer:
- where does Verifrax applicant intake live?
- what does
apply.verifrax.netown? - what is the intake boundary?
- how is intake separated from proof, verify, authority, and execution?
A reader should not land here expecting:
- API execution
- proof browsing
- proof verification
- authority issuance
- archive browsing
- chain artifact registration
For system understanding, the correct reading order is:
.github— governance perimeterVERIFRAX— authored source and evidence-root chain contextAUCTORISEAL— authority layerCORPIFORM— execution layerVERIFRAX-verify— verification surfaceproof— proof publication surfaceapply— intake surface
If a reader starts here and expects protocol authorship, they started on the wrong edge of the system.
This repository must be the sole owning repository for apply.verifrax.net.
That means:
- one host
- one owning repository
- one intake role
- no hidden deployment overlap with proof, verify, docs, or execution surfaces
If another repository can silently deploy the same host, the README truth is already broken.
This repository should remain compatible with:
- deterministic build behavior for the intake surface
- host-ownership clarity
- no cross-surface claim drift
- no execution/proof/authority overclaim
- no accidental conversion into a generic jobs board or marketing catch-all
The failure mode to avoid is not merely bad prose. It is role contamination.
This repository should preserve correct separation and correct links with:
But it must not flatten them into “one site that does everything.”
A reader should be able to answer these instantly:
- Does this repo own
apply.verifrax.net? Yes. - Is this repo intake-only? Yes.
- Does it issue authority? No.
- Does it execute governed runtime? No.
- Does it publish proof? No.
- Does it verify proof as the verifier surface? No.
- Does it register artifact-0005? No.
- Must it stay aligned with the artifact-0005 perimeter? Yes.
If those answers are not immediate, the README is still too weak.
Treat submission handling, intake-data exposure, cross-surface leakage, and unintended execution/proof coupling as security-relevant defects.
Do not use public issues for sensitive findings if a private route exists.
An intake surface that accidentally behaves like an execution or proof surface is not merely confusing; it breaks system separation.
A contribution here is wrong if it:
- turns intake into a generic marketing surface
- turns intake into a jobs claim surface with ungrounded promises
- turns intake into proof or verifier language
- turns intake into authority or runtime language
- claims artifact-0005 ownership or registration
- makes
apply.verifrax.netsound like anything other than the intake boundary - introduces role overlap with
proof,verify,api,auctoriseal,corpiform,sigillarium, ordocs
Apache License Version 2.0. See LICENSE.