{
  "records": [
    {
      "id": "route:/",
      "path": "/",
      "title": "Orientation before depth.",
      "summary": "A short first pass: who I am, what I am testing, and where to go next.",
      "section": "Page",
      "type": "page",
      "body": [
        "I am Yuanhao Chen, a builder in Germany. This site is a clear map of my public work around AI-native research workflows, work artifacts, and open threads: what I am building, why it matters, and where the limits still are.",
        "A short first pass: who I am, what I am testing, and where to go next.",
        "Stable article titles, short subtitles, and links to the full argument behind each entry.",
        "Public repositories, what they show, and where their boundaries are.",
        "Open threads and objections that can change the next build or note.",
        "Email, GitHub, public site, and a concrete first-message shape without extra contact theater."
      ],
      "keywords": [
        "Home",
        "00 / Home"
      ]
    },
    {
      "id": "route:/notes",
      "path": "/notes",
      "title": "Read the working notes.",
      "summary": "Stable article titles, short subtitles, and links to the full argument behind each entry.",
      "section": "Notes",
      "type": "page",
      "body": [
        "Stable article titles, short subtitles, and links to the full argument behind each entry.",
        "Publish bar: The claim, evidence, and challenge bar a draft must clear before it becomes public.",
        "Source trail: The kinds of public material that can make a question sharper, harder, or more useful."
      ],
      "keywords": [
        "Notes",
        "01 / Notes"
      ]
    },
    {
      "id": "route:/notes/publish-bar",
      "path": "/notes/publish-bar",
      "title": "What earns a public note.",
      "summary": "The claim, evidence, and challenge bar a draft must clear before it becomes public.",
      "section": "Notes",
      "type": "page",
      "body": [
        "The claim, evidence, and challenge bar a draft must clear before it becomes public."
      ],
      "keywords": [
        "Publish bar",
        "01.1 / Publish bar"
      ]
    },
    {
      "id": "route:/notes/source-trail",
      "path": "/notes/source-trail",
      "title": "What can change the questions.",
      "summary": "The kinds of public material that can make a question sharper, harder, or more useful.",
      "section": "Notes",
      "type": "page",
      "body": [
        "The kinds of public material that can make a question sharper, harder, or more useful."
      ],
      "keywords": [
        "Source trail",
        "01.2 / Source trail"
      ]
    },
    {
      "id": "route:/work",
      "path": "/work",
      "title": "Inspect the work.",
      "summary": "Public repositories, what they show, and where their boundaries are.",
      "section": "Work",
      "type": "page",
      "body": [
        "Public repositories, what they show, and where their boundaries are."
      ],
      "keywords": [
        "Work",
        "02 / Work"
      ]
    },
    {
      "id": "route:/open-threads",
      "path": "/open-threads",
      "title": "Follow what I am still testing.",
      "summary": "Open threads and objections that can change the next build or note.",
      "section": "Open Threads",
      "type": "page",
      "body": [
        "Open threads and objections that can change the next build or note.",
        "Boundaries: What prototypes, maps, and AI trust arguments do not prove yet.",
        "Update rules: How repeated objections, field evidence, and failed artifacts should change the work."
      ],
      "keywords": [
        "Open Threads",
        "03 / Open Threads"
      ]
    },
    {
      "id": "route:/open-threads/boundaries",
      "path": "/open-threads/boundaries",
      "title": "What I am not claiming yet.",
      "summary": "What prototypes, maps, and AI trust arguments do not prove yet.",
      "section": "Open Threads",
      "type": "page",
      "body": [
        "What prototypes, maps, and AI trust arguments do not prove yet."
      ],
      "keywords": [
        "Boundaries",
        "03.1 / Boundaries"
      ]
    },
    {
      "id": "route:/open-threads/update-rules",
      "path": "/open-threads/update-rules",
      "title": "What would change the work.",
      "summary": "How repeated objections, field evidence, and failed artifacts should change the work.",
      "section": "Open Threads",
      "type": "page",
      "body": [
        "How repeated objections, field evidence, and failed artifacts should change the work."
      ],
      "keywords": [
        "Update rules",
        "03.2 / Update rules"
      ]
    },
    {
      "id": "route:/contact",
      "path": "/contact",
      "title": "Use a verified contact path.",
      "summary": "Email, GitHub, public site, and a concrete first-message shape without extra contact theater.",
      "section": "Contact",
      "type": "page",
      "body": [
        "Email, GitHub, public site, and a concrete first-message shape without extra contact theater.",
        "Email: ie.yuanhao@tum.de. Best path for a concrete workflow, research question, market bottleneck, or trust boundary.",
        "GitHub: @89325516. Public repositories, project boundaries, and current build evidence live here.",
        "Website: yuanhaochen.dev. Canonical public map for notes, work, open threads, and contact.",
        "Location: Germany. Germany-based builder; useful context when the problem depends on European workflows or institutions.",
        "Fit gate: When a message is worth sending and what context makes it useful.",
        "Work style: How collaboration stays grounded in visible objects, concrete disagreement, and small proofs.",
        "Stay in orbit: Weak-tie signals that can keep a useful thread alive before a project exists.",
        "First reply: The map, evidence bar, or artifact target a strong first exchange can create."
      ],
      "keywords": [
        "Contact",
        "04 / Contact"
      ]
    },
    {
      "id": "route:/contact/fit",
      "path": "/contact/fit",
      "title": "Bring the constraint, not the pitch.",
      "summary": "When a message is worth sending and what context makes it useful.",
      "section": "Contact",
      "type": "page",
      "body": [
        "When a message is worth sending and what context makes it useful."
      ],
      "keywords": [
        "Fit gate",
        "04.1 / Fit gate"
      ]
    },
    {
      "id": "route:/contact/work-style",
      "path": "/contact/work-style",
      "title": "Serious, low-theater, artifact-first.",
      "summary": "How collaboration stays grounded in visible objects, concrete disagreement, and small proofs.",
      "section": "Contact",
      "type": "page",
      "body": [
        "How collaboration stays grounded in visible objects, concrete disagreement, and small proofs."
      ],
      "keywords": [
        "Work style",
        "04.2 / Work style"
      ]
    },
    {
      "id": "route:/contact/orbit",
      "path": "/contact/orbit",
      "title": "Small signals are enough to start.",
      "summary": "Weak-tie signals that can keep a useful thread alive before a project exists.",
      "section": "Contact",
      "type": "page",
      "body": [
        "Weak-tie signals that can keep a useful thread alive before a project exists."
      ],
      "keywords": [
        "Stay in orbit",
        "04.3 / Orbit"
      ]
    },
    {
      "id": "route:/contact/first-reply",
      "path": "/contact/first-reply",
      "title": "A good first message should turn into something inspectable.",
      "summary": "The map, evidence bar, or artifact target a strong first exchange can create.",
      "section": "Contact",
      "type": "page",
      "body": [
        "The map, evidence bar, or artifact target a strong first exchange can create."
      ],
      "keywords": [
        "First reply",
        "04.4 / First reply"
      ]
    },
    {
      "id": "route:/notes/ai-native-research-workflows",
      "path": "/notes/ai-native-research-workflows",
      "title": "AI-native research workflows: from a question to an evidence-linked memo",
      "summary": "A research workflow only becomes useful when a reader can still inspect why the judgment changed.",
      "section": "Notes",
      "type": "article",
      "body": [
        "AI-native research workflows: from a question to an evidence-linked memo",
        "A research workflow only becomes useful when a reader can still inspect why the judgment changed.",
        "The pressure",
        "The interesting part is no longer whether AI can summarize a pile of sources. The harder question is whether a serious reader can see which source changed the answer, which uncertainty survived, and which part of the memo is still a claim instead of evidence.",
        "Most AI research workflows still collapse the work into a polished paragraph too early. That makes the output easier to forward, but weaker to challenge.",
        "The shape I trust",
        "A useful memo should keep the question, source trail, judgment shifts, and objection path close together. The reader should not have to guess whether a sentence came from a source, a model synthesis, or my own interpretation.",
        "The workflow I want to test is simple: start with one decision pressure, attach the sources that actually moved the reasoning, write the memo around the changed judgment, and leave the next challenge visible.",
        "What I would inspect next",
        "I would inspect tools that make source state and uncertainty visible without turning the whole workflow into compliance theater. The important test is whether a reader can disagree with the memo faster because the evidence is still attached."
      ],
      "keywords": [
        "AI-native research workflows: from a question to an evidence-linked memo",
        "Note"
      ]
    },
    {
      "id": "route:/notes/enterprise-agent-permission-boundaries",
      "path": "/notes/enterprise-agent-permission-boundaries",
      "title": "Enterprise agents: where permission boundaries decide the category",
      "summary": "The impressive demo is not the category. The category starts when ownership, approval, rollback, and audit become visible.",
      "section": "Notes",
      "type": "article",
      "body": [
        "Enterprise agents: where permission boundaries decide the category",
        "The impressive demo is not the category. The category starts when ownership, approval, rollback, and audit become visible.",
        "The adoption cliff",
        "Many enterprise agent demos work until the moment someone asks who is allowed to approve, write, undo, or explain the action. That is not a minor implementation detail. It is often the real product boundary.",
        "The system can look intelligent while still being unusable if the human organization cannot see where authority lives.",
        "The map that matters",
        "The useful market map is not a list of agent vendors. It is a map of jobs, permissions, exception paths, audit requirements, handoff moments, and the cost of a quiet mistake.",
        "The strongest wedge may belong to the team that makes a narrow action inspectable and reversible before it makes the assistant more autonomous.",
        "What I would test",
        "I would start with workflows where the proposed action is valuable but not safe to commit silently: knowledge-base updates, diligence notes, document routing, CRM changes, and internal research handoffs."
      ],
      "keywords": [
        "Enterprise agents: where permission boundaries decide the category",
        "Note"
      ]
    },
    {
      "id": "route:/notes/semantic-video-meaning-layer",
      "path": "/notes/semantic-video-meaning-layer",
      "title": "Universal Semantic Video as a portable meaning layer",
      "summary": "Media becomes infrastructure when meaning, rights, provenance, and fallback can travel between tools.",
      "section": "Notes",
      "type": "article",
      "body": [
        "Universal Semantic Video as a portable meaning layer",
        "Media becomes infrastructure when meaning, rights, provenance, and fallback can travel between tools.",
        "The problem",
        "Video workflows already have containers, captions, streams, and provenance standards, but they still struggle to carry object meaning, segment intent, speaker context, rights, consent rules, and fallback behavior through many AI and human tools.",
        "When that meaning disappears, the next tool has to infer too much. The workflow becomes brittle even if the media file itself remains intact.",
        "The artifact",
        "The Universal Semantic Video repository explores a sidecar approach: keep the media in existing delivery systems, then add a small validated semantic layer that can be inspected independently.",
        "The useful boundary is that USV is not trying to become a codec, a player, or a hosted AI translation service. It is a portable meaning layer that can survive tool boundaries.",
        "What changed",
        "The project made the unit clearer for me. A richer caption is not enough. The inspectable object is the relationship between segment, speaker, object, right, fallback, and provenance.",
        "Inspect the repository",
        "https://github.com/89325516/universal-semantic-video"
      ],
      "keywords": [
        "Universal Semantic Video as a portable meaning layer",
        "Note"
      ]
    },
    {
      "id": "route:/notes/safe-ai-vault-writes",
      "path": "/notes/safe-ai-vault-writes",
      "title": "Safe AI-to-vault writes: why suggestion and commit should stay separate",
      "summary": "A useful assistant can prepare the change. A trustworthy system still needs review, confirmation, and rollback.",
      "section": "Notes",
      "type": "article",
      "body": [
        "Safe AI-to-vault writes: why suggestion and commit should stay separate",
        "A useful assistant can prepare the change. A trustworthy system still needs review, confirmation, and rollback.",
        "The boundary",
        "AI-assisted note systems become risky when the assistant can quietly mutate the user vault. The problem is not that the model writes text. The problem is that storage changed without a visible owner.",
        "Suggestion and commit are different responsibilities. Collapsing them makes the system feel smooth while making trust harder.",
        "The artifact",
        "The serverless vault bridge keeps the assistant in the proposal lane. It can prepare a diff, but the final write requires exact-content confirmation, digest binding, path safety, expected base SHA, and conflict handling.",
        "That adds friction on purpose. The friction is the point where ownership becomes visible again.",
        "What I would reuse",
        "The pattern is not limited to Markdown vaults. Any AI workflow that writes into durable systems should separate suggested change, reviewed change, committed change, and rollback story.",
        "Inspect the repository",
        "https://github.com/89325516/serverless-vault-bridge"
      ],
      "keywords": [
        "Safe AI-to-vault writes: why suggestion and commit should stay separate",
        "Note"
      ]
    },
    {
      "id": "route:/notes/after-the-ai-demo",
      "path": "/notes/after-the-ai-demo",
      "title": "What founders and operators actually distrust after the AI demo",
      "summary": "The best signal is often the objection that survives the demo: owner, audit trail, handoff, or consequence.",
      "section": "Notes",
      "type": "article",
      "body": [
        "What founders and operators actually distrust after the AI demo",
        "The best signal is often the objection that survives the demo: owner, audit trail, handoff, or consequence.",
        "The objection",
        "A good AI demo can remove the first objection and expose the real one. People often stop asking whether the model can produce something and start asking who owns the decision after the output appears.",
        "That objection is more useful than polite enthusiasm because it points to the missing system boundary.",
        "The pattern",
        "The distrust usually clusters around four moments: unclear owner, hidden source state, weak audit trail, and a handoff nobody wants to maintain. Those are not anti-AI complaints. They are product requirements showing up in operator language.",
        "The phrase people use in the room matters because it often names the real constraint better than the pitch deck does.",
        "What I want to collect",
        "I want more field notes where the demo worked technically but failed organizationally. The important detail is the sentence that made the room slow down."
      ],
      "keywords": [
        "What founders and operators actually distrust after the AI demo",
        "Note"
      ]
    },
    {
      "id": "route:/notes/inspectable-over-known",
      "path": "/notes/inspectable-over-known",
      "title": "Being known is weaker than being inspectable",
      "summary": "Reputation is too vague by itself. Work becomes easier to trust when the claims, limits, and evidence can be inspected.",
      "section": "Notes",
      "type": "article",
      "body": [
        "Being known is weaker than being inspectable",
        "Reputation is too vague by itself. Work becomes easier to trust when the claims, limits, and evidence can be inspected.",
        "The public signal",
        "Being known can create attention, but it does not create trust on its own. A serious visitor still needs to inspect how a person thinks, where the work exists, what the artifact proves, and where the claim stops.",
        "That is why I care more about evidence paths than broad visibility. The right reader should be able to disagree with something specific.",
        "The site logic",
        "The website should not behave like a resume with motion on top. It should behave like a small map of public work, working notes, proof boundaries, and useful questions.",
        "A note, repo, market map, or field signal earns its place when it makes the next serious conversation more concrete.",
        "What would make it stronger",
        "More public artifacts, sharper notes, and better boundaries would make the site stronger than more polish alone. The surface should stay attractive, but the trust comes from inspectable objects."
      ],
      "keywords": [
        "Being known is weaker than being inspectable",
        "Note"
      ]
    },
    {
      "id": "route:/work/datasentinel",
      "path": "/work/datasentinel",
      "title": "lawdit GDPR",
      "summary": "A governance-focused GDPR discovery prototype that scans selected sources, redacts evidence, routes owners, supports human review, and records audit events.",
      "section": "Work",
      "type": "article",
      "body": [
        "lawdit GDPR",
        "A governance-focused GDPR discovery prototype that scans selected sources, redacts evidence, routes owners, supports human review, and records audit events.",
        "Why this article exists",
        "This project started from a plain risk: a one-time PII scan can find sensitive data and still leave nobody accountable for the decision. I used the prototype to model the whole governance loop around scattered personal-data evidence, from discovery to redacted review to audit.",
        "Problem",
        "Organizations often know personal data is spread across documents, tables, archives, email exports, images, and shared drives. The hard part is proving what was found, who owns the review, which action is allowed, and whether the workflow improved.",
        "What shipped",
        "Python backend, scanner pipeline, review workflow, audit events, evaluation metrics, OpenAPI contract, Vite/React console, Fumadocs user guide, and controlled public demo flow.",
        "Evidence",
        "The README exposes the live demo, user guide, API contract, repository map, validation commands, and project boundaries around deletion, legal advice, and production tenant integrations.",
        "Inspect path",
        "Inspect the README first, then `contracts/openapi.yaml`, the product docs, backend review/audit modules, and tests around evidence assembly and review decisions.",
        "Boundary",
        "Deletion is simulated, the project is not legal advice, and it does not claim production tenant-wide Microsoft 365 inventory or deletion integration.",
        "What changed",
        "The useful boundary became clearer: sensitive-data AI is only credible when review state, redaction, owner routing, and audit events stay visible.",
        "Next question",
        "Which review event should become impossible to skip before a sensitive-data system earns trust?",
        "Open public repository",
        "https://github.com/89325516/datasentinel-gdpr"
      ],
      "keywords": [
        "lawdit GDPR",
        "Work article"
      ]
    },
    {
      "id": "route:/work/semantic-video",
      "path": "/work/semantic-video",
      "title": "universal-semantic-video",
      "summary": "An open semantic sidecar format for localization, accessibility, rights, provenance, fallback rendering, and tool-to-tool media inspection.",
      "section": "Work",
      "type": "article",
      "body": [
        "universal-semantic-video",
        "An open semantic sidecar format for localization, accessibility, rights, provenance, fallback rendering, and tool-to-tool media inspection.",
        "Why this article exists",
        "This repo asks what happens when video needs to travel through many AI and human tools without losing meaning. Instead of proposing a new codec or player, it keeps media in existing delivery systems and adds a validated semantic layer on the side.",
        "Problem",
        "Video workflows already have containers, captions, streams, and provenance standards, but they still struggle to say which objects, segments, speakers, rights, consent rules, and fallbacks should survive tool boundaries.",
        "What shipped",
        "JSON Schema for `.usv.json`, CLI init/validate/inspect/conformance commands, public-safe examples, WebVTT fallbacks, standards notes, roadmap, docs, and CI checks.",
        "Evidence",
        "The README documents the eight-section sidecar shape, core conformance rules, standards posture, public-safety hook, and explicit pre-1.0 limitations.",
        "Inspect path",
        "Inspect `schema/usv.schema.json`, `examples/lite/`, `docs/spec/USV-Core-Conformance.md`, `docs/STANDARDS.md`, and the CI workflow.",
        "Boundary",
        "USV is not a codec, player, hosted API, AI translation system, ASR/OCR pipeline, lip-sync tool, or native container embedding layer yet.",
        "What changed",
        "The useful unit became clearer: not a richer caption, but a small validated meaning layer that can survive tool boundaries without pretending to replace the media stack.",
        "Next question",
        "What would make semantic video evidence portable enough for real creative and review workflows?",
        "Open public repository",
        "https://github.com/89325516/universal-semantic-video"
      ],
      "keywords": [
        "universal-semantic-video",
        "Work article"
      ]
    },
    {
      "id": "route:/work/vault-bridge",
      "path": "/work/vault-bridge",
      "title": "serverless-vault-bridge",
      "summary": "A serverless Markdown vault bridge for ChatGPT Actions and MCP that separates proposed AI edits from committed GitHub writes.",
      "section": "Work",
      "type": "article",
      "body": [
        "serverless-vault-bridge",
        "A serverless Markdown vault bridge for ChatGPT Actions and MCP that separates proposed AI edits from committed GitHub writes.",
        "Why this article exists",
        "I built this around a small but important discomfort: if AI can help maintain a knowledge vault, it should not quietly mutate the vault behind the user. The bridge makes the assistant prepare a diff, then forces the final write through exact-content confirmation.",
        "Problem",
        "AI-assisted note systems need safe write boundaries: path safety, API authentication, diff review, digest-bound confirmation, expected base SHA, and conflict handling before storage changes.",
        "What shipped",
        "Cloudflare Worker-compatible runtime, GitHub Contents API storage adapter, ChatGPT Actions OpenAPI, MCP JSON-RPC endpoint, proposal tokens, path policy, CAS conflict handling, and behavior tests.",
        "Evidence",
        "The README names the propose-review-commit tool flow and failure semantics for path traversal, token mismatch, digest mismatch, path mismatch, base SHA mismatch, and CAS conflicts.",
        "Inspect path",
        "Inspect `src/`, `test/`, `wrangler.toml.example`, the OpenAPI schema, and tests for auth, path safety, token binding, CAS conflicts, and MCP parity.",
        "Boundary",
        "It is not a sync engine, database, agent framework, or direct write API for high-risk automation.",
        "What changed",
        "The important boundary became clearer: not chat versus agent, but suggestion versus commit, with ownership and rollback kept visible.",
        "Next question",
        "Where should approval live when AI can prepare a change but should not own the final mutation?",
        "Open public repository",
        "https://github.com/89325516/serverless-vault-bridge"
      ],
      "keywords": [
        "serverless-vault-bridge",
        "Work article"
      ]
    },
    {
      "id": "route:/work/tum-search",
      "path": "/work/tum-search",
      "title": "tum-search",
      "summary": "A TUM-focused search and knowledge-graph system combining recursive crawling, AI summaries, vector search, graph structure, and live crawl feedback.",
      "section": "Work",
      "type": "article",
      "body": [
        "tum-search",
        "A TUM-focused search and knowledge-graph system combining recursive crawling, AI summaries, vector search, graph structure, and live crawl feedback.",
        "Why this article exists",
        "Search is a good test of whether a system can respect both structure and intent. This project explores how university knowledge can be crawled, summarized, embedded, connected, and updated without treating ranking as only keyword matching.",
        "Problem",
        "Campus knowledge search needs more than text lookup: recursive crawling, concise page summaries, semantic retrieval, graph relationships, and visible progress when the index changes.",
        "What shipped",
        "Crawler, Gemini-powered summaries, Qdrant/CLIP vector search, knowledge graph ideas, WebSocket crawl progress, dependency checks, setup scripts, and admin utilities.",
        "Evidence",
        "The README documents the crawler, summarization, vector-search, knowledge-graph, WebSocket update, setup, environment, and admin-tool surfaces.",
        "Inspect path",
        "Inspect the README, `web_server.py`, dependency scripts, crawler/summarization paths, Qdrant configuration, and admin scripts for database clearing and summary regeneration.",
        "Boundary",
        "The public README exposes a research/prototype search system, not a production campus search service or validated ranking benchmark.",
        "What changed",
        "Search quality became a systems question: topology, semantics, generated summaries, and update feedback matter together before ranking claims are credible.",
        "Next question",
        "Which signal should be trusted first when graph structure and semantic similarity disagree?",
        "Open public repository",
        "https://github.com/89325516/tum-search"
      ],
      "keywords": [
        "tum-search",
        "Work article"
      ]
    },
    {
      "id": "route:/work/nitro-judge",
      "path": "/work/nitro-judge",
      "title": "nitro-ai-judge",
      "summary": "A public reading-time prediction repository with a reproducible baseline pipeline, data contract, local evaluation, and experiment boundaries.",
      "section": "Work",
      "type": "article",
      "body": [
        "nitro-ai-judge",
        "A public reading-time prediction repository with a reproducible baseline pipeline, data contract, local evaluation, and experiment boundaries.",
        "Why this article exists",
        "This project is useful because it shows restraint under leaderboard pressure. The repository keeps the baseline, data contract, local estimates, failed experiments, and promotion rules visible so model progress is not confused with wishful scoring.",
        "Problem",
        "A competition pipeline can look successful while hiding whether a score came from local validation, official feedback, leakage, oracle ceilings, or a lucky upload.",
        "What shipped",
        "CSV data contract, `solution.py`, generated submission, cross-validation evaluator, acceptance criteria, baseline design docs, target audit, and documented Transformer/BERT/semantic experiments.",
        "Evidence",
        "The README distinguishes local estimates from hidden Nitro leaderboard scores, documents a rejected BERT score, and states when experiments are not promoted.",
        "Inspect path",
        "Inspect `solution.py`, `evaluate.py`, `docs/submission_pipeline_design.md`, `ACCEPTANCE_CRITERIA.md`, experiment reports, and target-audit commands.",
        "Boundary",
        "Local validation is not the hidden leaderboard, and experimental models are not promoted unless local or official evidence supports them.",
        "What changed",
        "The baseline discipline became clearer: a plain model is useful when it protects error analysis, promotion rules, and evidence quality from leaderboard noise.",
        "Next question",
        "Which failure class would justify a more complex model instead of cleaner data, features, or evaluation?",
        "Open public repository",
        "https://github.com/89325516/nitro-ai-judge"
      ],
      "keywords": [
        "nitro-ai-judge",
        "Work article"
      ]
    },
    {
      "id": "route:/work/aisd-redesign",
      "path": "/work/aisd-redesign",
      "title": "aisd-cinematic-redesign",
      "summary": "A derivative cinematic frontend redesign for an AI-assisted coding-assessment platform with explicit attribution and module-boundary notes.",
      "section": "Work",
      "type": "article",
      "body": [
        "aisd-cinematic-redesign",
        "A derivative cinematic frontend redesign for an AI-assisted coding-assessment platform with explicit attribution and module-boundary notes.",
        "Why this article exists",
        "This project is where visual craft had to serve an operational interface. The redesign is not just about making an academic platform look cinematic; it is about pacing student/admin workflows, browser IDE state, AI assistance, submission evaluation, and reporting without blurring security boundaries.",
        "Problem",
        "A coding-assessment product needs clearer hierarchy, workspace persistence, role-based administration, AI-assistance boundaries, and frontend/backend contract clarity.",
        "What shipped",
        "Next.js frontend redesign, ASP.NET backend context, HyperFrames motion source, rendered motion media, frontend API client, Figma reference, design discussion, attribution, and acceptance criteria.",
        "Evidence",
        "The README records the upstream commit, unlicensed-source boundary, attribution file, module responsibilities, useful routes, backend assumptions, API notes, and security rules.",
        "Inspect path",
        "Inspect `ATTRIBUTION.md`, `FINAL_ACCEPTANCE_CRITERIA.md`, `docs/frontend-cinematic-redesign-discussion.md`, `hyperframes/aisd-motion/`, and frontend workspace routes.",
        "Boundary",
        "The repository is a derivative redesign of an upstream academic project; attribution is explicit and does not claim a license grant from the upstream source.",
        "What changed",
        "The craft boundary became clearer: motion is useful only when it clarifies hierarchy, pacing, and the next object a student or admin should inspect.",
        "Next question",
        "Which interaction should become calmer before the motion system becomes more ambitious?",
        "Open public repository",
        "https://github.com/89325516/aisd-cinematic-redesign"
      ],
      "keywords": [
        "aisd-cinematic-redesign",
        "Work article"
      ]
    },
    {
      "id": "route:/open-threads/trusted-workflow-infrastructure",
      "path": "/open-threads/trusted-workflow-infrastructure",
      "title": "Trusted workflow infrastructure",
      "summary": "When does an AI agent stop being an impressive demo and start becoming trusted workflow infrastructure?",
      "section": "Open Threads",
      "type": "article",
      "body": [
        "Trusted workflow infrastructure",
        "When does an AI agent stop being an impressive demo and start becoming trusted workflow infrastructure?",
        "The question",
        "I am looking for the moment where audit, permissions, ownership, and rollback matter more than raw model ability.",
        "The useful threshold is not whether the agent can complete a task once. It is whether the workflow keeps authority, state, and reversal visible when the task becomes part of a real organization.",
        "Why it matters",
        "A demo can hide the hard parts by keeping the user, data, and failure surface narrow. Workflow infrastructure has to survive handoff, exception handling, review pressure, and the moment a quiet write could become expensive.",
        "What would change it",
        "The strongest evidence would be an operator using the system on a real workflow and naming which audit event, approval step, rollback path, or permission boundary made the difference between useful automation and a risky assistant."
      ],
      "keywords": [
        "Trusted workflow infrastructure",
        "Open thread"
      ]
    },
    {
      "id": "route:/open-threads/evidence-linked-memo",
      "path": "/open-threads/evidence-linked-memo",
      "title": "Evidence-linked memo",
      "summary": "What should a memo prove before someone uses it for investment or operating decisions?",
      "section": "Open Threads",
      "type": "article",
      "body": [
        "Evidence-linked memo",
        "What should a memo prove before someone uses it for investment or operating decisions?",
        "The question",
        "The hard part is not producing a clean answer. It is preserving source state, uncertainty, and the judgment path that led there.",
        "A memo becomes useful when a reader can see which evidence changed the judgment, where confidence is still weak, and which sentence should be challenged first.",
        "Why it matters",
        "A polished answer can travel faster than its evidence. That is dangerous in investment and operating contexts because the reader may inherit the confidence without inheriting the source trail or the remaining uncertainty.",
        "What would change it",
        "The next useful artifact would be a memo format where source state, objection path, and claim strength stay close enough that disagreement produces a better memo instead of a private argument."
      ],
      "keywords": [
        "Evidence-linked memo",
        "Open thread"
      ]
    },
    {
      "id": "route:/open-threads/structure-before-model-novelty",
      "path": "/open-threads/structure-before-model-novelty",
      "title": "Structure before model novelty",
      "summary": "Which European B2B workflows are ready for AI because the bottleneck is structure, not model novelty?",
      "section": "Open Threads",
      "type": "article",
      "body": [
        "Structure before model novelty",
        "Which European B2B workflows are ready for AI because the bottleneck is structure, not model novelty?",
        "The question",
        "I care about the less glamorous constraints: procurement, compliance, fragmented data, review habits, and operator trust.",
        "The category is more interesting when the bottleneck is not model capability alone. Some workflows need clearer state, owner routing, and evidence discipline before another model improvement matters.",
        "Why it matters",
        "European B2B workflows often expose the organizational constraint before the technical one. The buyer may believe the output and still reject the workflow if approval, audit, data boundaries, or accountability remain unclear.",
        "What would change it",
        "Repeated field objections from people who own the workflow budget, risk, or implementation burden would make the map more useful than another abstract list of AI opportunities."
      ],
      "keywords": [
        "Structure before model novelty",
        "Open thread"
      ]
    },
    {
      "id": "route:/open-threads/prototype-evidence-boundary",
      "path": "/open-threads/prototype-evidence-boundary",
      "title": "Prototype evidence is not deployment evidence",
      "summary": "A runnable repo can prove a boundary, contract, or workflow shape. It does not prove adoption, reliability, security posture, or procurement fit.",
      "section": "Open Threads",
      "type": "article",
      "body": [
        "Prototype evidence is not deployment evidence",
        "A runnable repo can prove a boundary, contract, or workflow shape. It does not prove adoption, reliability, security posture, or procurement fit.",
        "The boundary",
        "A runnable repo can prove a boundary, contract, or workflow shape. It does not prove adoption, reliability, security posture, or procurement fit.",
        "This boundary matters because a prototype can be genuinely useful and still say very little about production operations, security posture, procurement reality, or long-term maintenance.",
        "The evidence gap",
        "The question is not whether the prototype should exist. The question is whether the public claim stays narrow enough that the artifact improves the conversation without pretending to be deployment proof.",
        "What would change it",
        "A useful next signal would be an operator using the artifact on a real workflow and naming where it breaks under real constraints."
      ],
      "keywords": [
        "Prototype evidence is not deployment evidence",
        "Open thread"
      ]
    },
    {
      "id": "route:/open-threads/ai-trust-system-property",
      "path": "/open-threads/ai-trust-system-property",
      "title": "AI trust is a system property",
      "summary": "Model quality matters, but permissions, source state, review state, audit, and handoff often decide whether the system is usable.",
      "section": "Open Threads",
      "type": "article",
      "body": [
        "AI trust is a system property",
        "Model quality matters, but permissions, source state, review state, audit, and handoff often decide whether the system is usable.",
        "The boundary",
        "Model quality matters, but permissions, source state, review state, audit, and handoff often decide whether the system is usable.",
        "This is why I distrust category claims that only compare model output. The system either keeps evidence and ownership visible across the decision path, or it forces people to trust a result they cannot inspect.",
        "The evidence gap",
        "The useful proof is a workflow that makes the right thing harder to skip: source capture, owner assignment, review state, audit event, and a rollback story that survives outside the demo.",
        "What would change it",
        "A useful next signal would be a prototype that preserves evidence and ownership across the full decision path."
      ],
      "keywords": [
        "AI trust is a system property",
        "Open thread"
      ]
    },
    {
      "id": "route:/open-threads/artifacts-beat-forecasts",
      "path": "/open-threads/artifacts-beat-forecasts",
      "title": "Artifacts beat confident forecasts",
      "summary": "Update the proof standard before expanding the claim or writing the next thesis update.",
      "section": "Open Threads",
      "type": "article",
      "body": [
        "Artifacts beat confident forecasts",
        "Update the proof standard before expanding the claim or writing the next thesis update.",
        "The signal",
        "A small prototype exposes a state, permission, or evidence failure the thesis missed.",
        "The artifact matters because it can make a confident forecast more honest. A prototype, memo, or repo can show the missing state, failure path, or review burden that a clean thesis did not force into view.",
        "The update",
        "Update the proof standard before expanding the claim or writing the next thesis update.",
        "That update should happen before the next polished claim. If the proof bar changes, the public argument should change with it.",
        "What would change it",
        "The next useful signal would be an artifact that either survives the new proof standard or makes the original claim narrower, more concrete, and easier to challenge."
      ],
      "keywords": [
        "Artifacts beat confident forecasts",
        "Open thread"
      ]
    },
    {
      "id": "route:/search",
      "path": "/search",
      "title": "Search the public site.",
      "summary": "Find public notes, work evidence, open threads, and verified contact paths from one source-backed static index.",
      "section": "Search",
      "type": "page",
      "body": [
        "Find public notes, work evidence, open threads, and verified contact paths from one source-backed static index.",
        "Search records are generated from public pages, articles, verified projects, and verified contact channels.",
        "OpenSearch metadata and JSON search indexes are available for browsers and AI agents."
      ],
      "keywords": [
        "Search",
        "05 / Search"
      ]
    },
    {
      "id": "project:datasentinel",
      "path": "/work/datasentinel",
      "title": "lawdit GDPR",
      "summary": "A governance-focused GDPR discovery prototype that scans selected sources, redacts evidence, routes owners, supports human review, and records audit events.",
      "section": "Projects",
      "type": "project",
      "body": [
        "This project started from a plain risk: a one-time PII scan can find sensitive data and still leave nobody accountable for the decision. I used the prototype to model the whole governance loop around scattered personal-data evidence, from discovery to redacted review to audit.",
        "Organizations often know personal data is spread across documents, tables, archives, email exports, images, and shared drives. The hard part is proving what was found, who owns the review, which action is allowed, and whether the workflow improved.",
        "Python backend, scanner pipeline, review workflow, audit events, evaluation metrics, OpenAPI contract, Vite/React console, Fumadocs user guide, and controlled public demo flow.",
        "The README exposes the live demo, user guide, API contract, repository map, validation commands, and project boundaries around deletion, legal advice, and production tenant integrations.",
        "Inspect the README first, then `contracts/openapi.yaml`, the product docs, backend review/audit modules, and tests around evidence assembly and review decisions.",
        "Deletion is simulated, the project is not legal advice, and it does not claim production tenant-wide Microsoft 365 inventory or deletion integration.",
        "The useful boundary became clearer: sensitive-data AI is only credible when review state, redaction, owner routing, and audit events stay visible.",
        "Which review event should become impossible to skip before a sensitive-data system earns trust?",
        "https://github.com/89325516/datasentinel-gdpr"
      ],
      "keywords": [
        "Data",
        "Python"
      ]
    },
    {
      "id": "project:semantic-video",
      "path": "/work/semantic-video",
      "title": "universal-semantic-video",
      "summary": "An open semantic sidecar format for localization, accessibility, rights, provenance, fallback rendering, and tool-to-tool media inspection.",
      "section": "Projects",
      "type": "project",
      "body": [
        "This repo asks what happens when video needs to travel through many AI and human tools without losing meaning. Instead of proposing a new codec or player, it keeps media in existing delivery systems and adds a validated semantic layer on the side.",
        "Video workflows already have containers, captions, streams, and provenance standards, but they still struggle to say which objects, segments, speakers, rights, consent rules, and fallbacks should survive tool boundaries.",
        "JSON Schema for `.usv.json`, CLI init/validate/inspect/conformance commands, public-safe examples, WebVTT fallbacks, standards notes, roadmap, docs, and CI checks.",
        "The README documents the eight-section sidecar shape, core conformance rules, standards posture, public-safety hook, and explicit pre-1.0 limitations.",
        "Inspect `schema/usv.schema.json`, `examples/lite/`, `docs/spec/USV-Core-Conformance.md`, `docs/STANDARDS.md`, and the CI workflow.",
        "USV is not a codec, player, hosted API, AI translation system, ASR/OCR pipeline, lip-sync tool, or native container embedding layer yet.",
        "The useful unit became clearer: not a richer caption, but a small validated meaning layer that can survive tool boundaries without pretending to replace the media stack.",
        "What would make semantic video evidence portable enough for real creative and review workflows?",
        "https://github.com/89325516/universal-semantic-video"
      ],
      "keywords": [
        "Media",
        "TypeScript"
      ]
    },
    {
      "id": "project:vault-bridge",
      "path": "/work/vault-bridge",
      "title": "serverless-vault-bridge",
      "summary": "A serverless Markdown vault bridge for ChatGPT Actions and MCP that separates proposed AI edits from committed GitHub writes.",
      "section": "Projects",
      "type": "project",
      "body": [
        "I built this around a small but important discomfort: if AI can help maintain a knowledge vault, it should not quietly mutate the vault behind the user. The bridge makes the assistant prepare a diff, then forces the final write through exact-content confirmation.",
        "AI-assisted note systems need safe write boundaries: path safety, API authentication, diff review, digest-bound confirmation, expected base SHA, and conflict handling before storage changes.",
        "Cloudflare Worker-compatible runtime, GitHub Contents API storage adapter, ChatGPT Actions OpenAPI, MCP JSON-RPC endpoint, proposal tokens, path policy, CAS conflict handling, and behavior tests.",
        "The README names the propose-review-commit tool flow and failure semantics for path traversal, token mismatch, digest mismatch, path mismatch, base SHA mismatch, and CAS conflicts.",
        "Inspect `src/`, `test/`, `wrangler.toml.example`, the OpenAPI schema, and tests for auth, path safety, token binding, CAS conflicts, and MCP parity.",
        "It is not a sync engine, database, agent framework, or direct write API for high-risk automation.",
        "The important boundary became clearer: not chat versus agent, but suggestion versus commit, with ownership and rollback kept visible.",
        "Where should approval live when AI can prepare a change but should not own the final mutation?",
        "https://github.com/89325516/serverless-vault-bridge"
      ],
      "keywords": [
        "Infrastructure",
        "JavaScript"
      ]
    },
    {
      "id": "project:tum-search",
      "path": "/work/tum-search",
      "title": "tum-search",
      "summary": "A TUM-focused search and knowledge-graph system combining recursive crawling, AI summaries, vector search, graph structure, and live crawl feedback.",
      "section": "Projects",
      "type": "project",
      "body": [
        "Search is a good test of whether a system can respect both structure and intent. This project explores how university knowledge can be crawled, summarized, embedded, connected, and updated without treating ranking as only keyword matching.",
        "Campus knowledge search needs more than text lookup: recursive crawling, concise page summaries, semantic retrieval, graph relationships, and visible progress when the index changes.",
        "Crawler, Gemini-powered summaries, Qdrant/CLIP vector search, knowledge graph ideas, WebSocket crawl progress, dependency checks, setup scripts, and admin utilities.",
        "The README documents the crawler, summarization, vector-search, knowledge-graph, WebSocket update, setup, environment, and admin-tool surfaces.",
        "Inspect the README, `web_server.py`, dependency scripts, crawler/summarization paths, Qdrant configuration, and admin scripts for database clearing and summary regeneration.",
        "The public README exposes a research/prototype search system, not a production campus search service or validated ranking benchmark.",
        "Search quality became a systems question: topology, semantics, generated summaries, and update feedback matter together before ranking claims are credible.",
        "Which signal should be trusted first when graph structure and semantic similarity disagree?",
        "https://github.com/89325516/tum-search"
      ],
      "keywords": [
        "Search",
        "Python"
      ]
    },
    {
      "id": "project:nitro-judge",
      "path": "/work/nitro-judge",
      "title": "nitro-ai-judge",
      "summary": "A public reading-time prediction repository with a reproducible baseline pipeline, data contract, local evaluation, and experiment boundaries.",
      "section": "Projects",
      "type": "project",
      "body": [
        "This project is useful because it shows restraint under leaderboard pressure. The repository keeps the baseline, data contract, local estimates, failed experiments, and promotion rules visible so model progress is not confused with wishful scoring.",
        "A competition pipeline can look successful while hiding whether a score came from local validation, official feedback, leakage, oracle ceilings, or a lucky upload.",
        "CSV data contract, `solution.py`, generated submission, cross-validation evaluator, acceptance criteria, baseline design docs, target audit, and documented Transformer/BERT/semantic experiments.",
        "The README distinguishes local estimates from hidden Nitro leaderboard scores, documents a rejected BERT score, and states when experiments are not promoted.",
        "Inspect `solution.py`, `evaluate.py`, `docs/submission_pipeline_design.md`, `ACCEPTANCE_CRITERIA.md`, experiment reports, and target-audit commands.",
        "Local validation is not the hidden leaderboard, and experimental models are not promoted unless local or official evidence supports them.",
        "The baseline discipline became clearer: a plain model is useful when it protects error analysis, promotion rules, and evidence quality from leaderboard noise.",
        "Which failure class would justify a more complex model instead of cleaner data, features, or evaluation?",
        "https://github.com/89325516/nitro-ai-judge"
      ],
      "keywords": [
        "ML",
        "Python"
      ]
    },
    {
      "id": "project:aisd-redesign",
      "path": "/work/aisd-redesign",
      "title": "aisd-cinematic-redesign",
      "summary": "A derivative cinematic frontend redesign for an AI-assisted coding-assessment platform with explicit attribution and module-boundary notes.",
      "section": "Projects",
      "type": "project",
      "body": [
        "This project is where visual craft had to serve an operational interface. The redesign is not just about making an academic platform look cinematic; it is about pacing student/admin workflows, browser IDE state, AI assistance, submission evaluation, and reporting without blurring security boundaries.",
        "A coding-assessment product needs clearer hierarchy, workspace persistence, role-based administration, AI-assistance boundaries, and frontend/backend contract clarity.",
        "Next.js frontend redesign, ASP.NET backend context, HyperFrames motion source, rendered motion media, frontend API client, Figma reference, design discussion, attribution, and acceptance criteria.",
        "The README records the upstream commit, unlicensed-source boundary, attribution file, module responsibilities, useful routes, backend assumptions, API notes, and security rules.",
        "Inspect `ATTRIBUTION.md`, `FINAL_ACCEPTANCE_CRITERIA.md`, `docs/frontend-cinematic-redesign-discussion.md`, `hyperframes/aisd-motion/`, and frontend workspace routes.",
        "The repository is a derivative redesign of an upstream academic project; attribution is explicit and does not claim a license grant from the upstream source.",
        "The craft boundary became clearer: motion is useful only when it clarifies hierarchy, pacing, and the next object a student or admin should inspect.",
        "Which interaction should become calmer before the motion system becomes more ambitious?",
        "https://github.com/89325516/aisd-cinematic-redesign"
      ],
      "keywords": [
        "Interface",
        "C#"
      ]
    },
    {
      "id": "contact:email",
      "path": "/contact",
      "title": "Email",
      "summary": "ie.yuanhao@tum.de. Best path for a concrete workflow, research question, market bottleneck, or trust boundary.",
      "section": "Contact",
      "type": "contact",
      "body": [
        "ie.yuanhao@tum.de",
        "mailto:ie.yuanhao@tum.de",
        "Write email",
        "Best path for a concrete workflow, research question, market bottleneck, or trust boundary."
      ],
      "keywords": [
        "verified contact",
        "account path",
        "Email"
      ]
    },
    {
      "id": "contact:github",
      "path": "/contact",
      "title": "GitHub",
      "summary": "@89325516. Public repositories, project boundaries, and current build evidence live here.",
      "section": "Contact",
      "type": "contact",
      "body": [
        "@89325516",
        "https://github.com/89325516",
        "Inspect profile",
        "Public repositories, project boundaries, and current build evidence live here."
      ],
      "keywords": [
        "verified contact",
        "account path",
        "GitHub"
      ]
    },
    {
      "id": "contact:website",
      "path": "/contact",
      "title": "Website",
      "summary": "yuanhaochen.dev. Canonical public map for notes, work, open threads, and contact.",
      "section": "Contact",
      "type": "contact",
      "body": [
        "yuanhaochen.dev",
        "https://yuanhaochen.dev",
        "Open site",
        "Canonical public map for notes, work, open threads, and contact."
      ],
      "keywords": [
        "verified contact",
        "account path",
        "Website"
      ]
    },
    {
      "id": "contact:location",
      "path": "/contact",
      "title": "Location",
      "summary": "Germany. Germany-based builder; useful context when the problem depends on European workflows or institutions.",
      "section": "Contact",
      "type": "contact",
      "body": [
        "Germany",
        "mailto:ie.yuanhao@tum.de?subject=Concrete%20problem%20from%20Germany%20%2F%20Europe%20context",
        "Send context",
        "Germany-based builder; useful context when the problem depends on European workflows or institutions."
      ],
      "keywords": [
        "verified contact",
        "account path",
        "Location"
      ]
    }
  ]
}