# hessian AI & JAIF on Hugging Face

The central reading surface is the [hessian AI & JAIF website](https://ctauchmann-hessian-recipes.static.hf.space/),
a **Protected Static Space** under the personal `ctauchmann/hessian-recipes`
namespace. Its pages contain the recipe catalogue,
setup guides, measured evidence, research references and domain sketches. The
Space also contains runnable source, tests, dependency files and authored fixtures;
GitHub is the collaborative source of truth for changes, review and issue tracking.
The Space is a generated publication of a specific source commit. Recipe pages link to
upstream model/dataset cards and explain local artifacts; this hub does not contain weights,
downloaded training data, raw model outputs or private run directories.
Model and dataset publication is outside this workflow.


The App is a public research website: a factual overview, an experimental
protocol, a searchable methods index, interactive pilot-result
comparisons, benchmark proposals and domain sketches. Guide pages share the same
layout and add an on-page contents list and copyable code examples. These features
work in the Protected Static Space. Share the direct App address above: it needs
no login and includes the approved downloadable source files. The Hugging Face
repository page and Git clone remain private, as does the development repository
on GitHub. Organization profile cards remain deferred.

Result charts are built from the exact committed aggregate evidence included in
the source snapshot. They retain sample sizes, inconclusive outcomes and the
failed retention gate. They do not read cluster logs or claim live experiment
status. The site uses local HTML, CSS, SVG and JavaScript with no runtime external
fonts, analytics or model calls; the content remains readable without JavaScript.
Typography and purple/lavender colors follow the
[hessian.AI website](https://www.hessian.ai/); the joint identity includes the
official JAIF logo from [jaif.ai](https://jaif.ai/). Selected official assets are
self-hosted with [source URLs, checksums and rights scope](brand/provenance.json);
the Poppins SIL Open Font License is included. The project-index presentation
also draws on [FineEnvs](https://huggingface.co/FineEnvs): concise scope,
methods, implementation links, results and explicit qualification status.
The [interface validation](../../docs/huggingface-ui-validation.json) records
desktop/mobile browser checks, accessibility findings and the reviewed fixes.

As of 21 October 2026, the longer NeMo and matched OpenEnv attempts stopped at
the GPU token-audit qualification. No longer-run quality result is available;
existing pilot results retain their original limitations. See the
[current programme status](../../docs/programme-status.md).

The Protected App is live, with public recipe/source pages and a separate
[private upstream-reference collection](https://huggingface.co/collections/ctauchmann/hessian-recipes-private-research-workspace-6ad7417d810d666542981033).
Anonymous visitors can read the website and its source downloads; anonymous Hub
repository access is denied. The account's private-storage restriction previously
blocked authenticated repository resolve downloads; a fresh remote HF clone has
not been qualified. Use GitHub for the development checkout. The dated
[publication evidence](../../docs/huggingface-publication.json) records the earlier
Private deployment and its access limits; its anonymous-App-denial findings are
historical, not the current Protected visibility contract.

## Native Hub features and visibility

| Feature | Use here | Visibility boundary |
| --- | --- | --- |
| [Static HTML Space](https://huggingface.co/docs/hub/spaces-sdks-static) | Multi-page recipe and evidence homepage, served without a compute instance. | Protected visibility makes the App and its approved source downloads public while keeping the Space repository private. |
| [Collections](https://huggingface.co/docs/hub/collections) | Curated lists of related models, datasets, Spaces and papers, with concise item notes. | Personal collections can be private. Private collections do not appear as public profile highlights. Collection visibility does not replace each repository's own access controls. |
| [Model cards](https://huggingface.co/docs/hub/model-cards) and [dataset cards](https://huggingface.co/docs/hub/datasets-cards) | Link to upstream ancestry, use, evaluation, limitations and terms; keep this project's local artifact notes in recipe pages. | No model or dataset repository is uploaded in this phase. |
| [Organization card](https://huggingface.co/docs/hub/organizations-cards) | A future institutional navigation page linking the catalogue and release families. | HF displays a card from a **public Space named README**. A private/protected Space does not display an organization card; organization cards remain deferred. |
| [Blog articles](https://huggingface.co/docs/hub/blog-articles) | Later public explanations of recipes or research releases. | No public article or profile is edited by this workflow. Keep unpublished working notes in the private GitHub checkout. |

Static Spaces use `sdk: static` and `app_file: index.html`. The generated site is
self-contained: no external scripts, analytics, model calls or provider keys.
Its build manifest records the exact source bytes and generated files.
Publication validates the approved personal namespace, target repository and
explicit Protected visibility, then verifies the resulting commit and visibility.
Private visibility remains available as an explicit deployment mode and the CLI
default; neither mode silently changes the existing Space's visibility.

## Reusable institutional patterns

These are publishing patterns, not evidence that their model results transfer to
this project. Profiles were inspected on 20 October 2026.

- [Ai2 / AllenAI](https://huggingface.co/allenai) groups complete project families
  in collections. For example, its AstaBrief collection connects SFT and DPO
  checkpoints with the corresponding training mixtures; leaderboard Spaces give
  evaluation its own destination. Reuse the recipe → data → model → evidence links.
- [NVIDIA](https://huggingface.co/nvidia) uses a structured organization card with
  sections for model families, datasets, frameworks, demonstrations and technical
  reports. Reuse capability-based entry blocks and links to concrete artifacts,
  while keeping implementation and qualification boundaries explicit.
- [Stanford CRFM](https://huggingface.co/stanford-crfm) provides a research-group
  namespace connecting its model work to the institutional project identity.
  Reuse consistent project naming and provenance, without implying affiliation.
- [LeoLM](https://huggingface.co/LeoLM) provides a focused German-model project
  identity. Reuse a dedicated language-adaptation entry rather than placing every
  experiment into a generic institutional model list.

For this project, start with recipe pages grouped by user task and references to
upstream models, datasets and papers. A private collection can group those links. An institutional public
profile and research articles are later publication decisions.

## Build and review locally

From the repository root, in the dependency-free core environment:

```bash
.venv/bin/python -m hessian_recipes.hf_recipe_hub \
  --output runs/huggingface/recipe-hub-review --visibility protected
python -m http.server 8090 --directory runs/huggingface/recipe-hub-review
```

Open the local page, review `hub-manifest.json`, and use a fresh build directory
for each snapshot. An explicit allowlist selects tracked source, dependencies,
scripts, tests, documentation, cards and small authored development fixtures.
Unrelated repository files, `.env` files, tokens, ignored run data and weights are
excluded. Executable-source links resolve to the included snapshot. Start at
[Run from Hugging Face](RUN.md) for the snapshot layout and authenticated
repository-clone route without a GitHub dependency.

Publication uses the optional installed `huggingface_hub` client and an already
authenticated personal account. The approved target is only
`ctauchmann/hessian-recipes` with repository type `space` and explicit Protected visibility.
There is no implicit collection, organization, blog or model publication.

## Publish after GitHub checks

[Deploy Hugging Face site](../../.github/workflows/deploy-huggingface.yml)
publishes the generated site after the `checks` workflow succeeds for a push to
`main` in this repository. Pull-request and fork runs cannot publish. It checks
out the exact tested commit, builds the allowlisted snapshot and validates local
links in a job without Hugging Face authentication. A separate publication job
uses GitHub OIDC with `huggingface_hub==1.33.0` to obtain short-lived credentials
for `spaces/ctauchmann/hessian-recipes`.

CI explicitly uses `publish --visibility protected --verification repository`.
It independently rebuilds the source bundle, checks the approved Protected target,
and publishes with the existing repository head as a compare-and-swap condition.
It verifies the exact remote repository files, then the publicly served manifest,
assets and source files. Before and after publication, it requires public App
access and denial of anonymous Hub raw-file access. In Protected mode its receipt
records `served_manifest_matches: true` and `app_verified_by_ci: true`; no App JWT
is needed to read the public site.

During the earlier Private deployment on 21 October 2026, the repository-scoped
OIDC publisher could upload and inspect
the private Space, but its request to mint an App-access JWT returned HTTP 401.
That historical CI receipt recorded `served_manifest_matches: null` and
`app_verified_by_ci: false`. Protected deployment verifies the public App directly.
The [separate App check](RUN.md#check-the-published-protected-app) can also run from
JAIF using local credentials outside the checkout; no personal token is stored in
GitHub. The publisher's default verification mode remains strict; Private mode
retains authenticated App verification or an explicitly chosen repository-only check.

For Private mode, the authenticated check obtains a five-minute Space JWT from
the first-party
`/api/spaces/{namespace}/{repo}/jwt` endpoint and verifies the manifest using
`__sign`. The endpoint is described in Hugging Face's
[OpenAPI schema](https://huggingface.co/.well-known/openapi.json).
Tokens stay in memory; signed URLs are never logged or saved in receipts.

The Space must have a [Hugging Face Trusted Publisher](https://huggingface.co/docs/hub/trusted-publishers)
registration with these exact claims: repository `ChTauchmann/hessian-recipes`,
branch `main`, and workflow `deploy-huggingface.yml`. The build job cannot mint OIDC tokens;
only the publication job has `id-token: write`, and `HF_OIDC_RESOURCE` is scoped
to its publication step. No stored `HF_TOKEN` repository secret is required. Do
not place a user token in source files, workflow inputs or clone URLs.

HF attributes these repository-scoped writes to its synthetic OIDC publisher;
this is separate from interactive publication with the owning personal account.
Both paths restrict the target to the approved Space and require its selected
visibility to match the explicit build/publication mode.

The workflow serializes publications and does not cancel an upload in progress.
Before uploading, it verifies that anonymous requests can read the existing
Protected website but cannot read raw files from the Hub repository; it repeats
these checks after publication. A repository visibility flag alone does not pass
the checks. The website includes the approved source downloads even though Hub
Git access remains private. This workflow builds website files only and never starts
cluster training or evaluation jobs.
It rechecks that the candidate is the current `main` commit and has successful
push `checks` before publishing, so an older queued run cannot replace a newer
source snapshot. After upload it verifies remote repository file identities and
the public served manifest/assets/source files and denial of anonymous Hub
raw-file access, then writes a deployment receipt and build manifest to a
seven-day Actions artifact. Protected App verification is part of successful CI
deployment. The static
bundle passed between jobs is retained for one day. It does not publish models,
datasets, collections or profile cards.

For a retry after fixing a transient hosting error or configuring the publisher,
open **Actions → Deploy Hugging Face site → Run workflow** and select
`main`. Manual runs require successful push checks for that same current commit. A
deployment failure does not change source history; inspect that workflow's log
and receipt before retrying. Automated source/build checks do not replace the
recorded browser and model-quality qualification.

The earlier Private-mode companion-collection helper follows the official
[collection API](https://huggingface.co/docs/huggingface_hub/guides/collections).
It requires a verified Private Space receipt and creates only a private list of
links: this Space, upstream Qwen3-1.7B, MathOctopus and MGSM. Its notes distinguish
training data from evaluation and record that the earlier MGSM64 subset was
already inspected. It copies no upstream files and changes no public profile.
The existing private collection is separate from the Protected website deployment.