Case study · Knowledge systems

Ayin Wiki

Knowledge lived in PDFs, exports, and shared drives. People couldn’t search one place, and agents had nothing structured to call. Ayin Wiki is one corpus for both: upload raw docs, pass a fail-closed PHI gate, regenerate pages with Bedrock, and serve the same content in the app and over an MCP server—with Okta so individuals can connect their own agents.

Role
Principal Product Designer
Team
AI Accelerator
When
Design system + knowledge platform
Impact
MCP + Okta · PHI gate · LLM design system
1 corpus
SPA readers and MCP agents share pages
Okta
SPA + MCP: same identity for people and agents
2-stage
PII/PHI gate before content is trusted
LLM DS
Figma system packaged for model use
AWS BedrockMCP · OktaPHI gateDesign system
Ayin Wiki home with category cards and workspace shell
Workspace home: browse, search, Ask AI, admin

The problem

Ask someone where they find the answer and you get a shrug: PDFs, exports, transcripts, shared drives, a Slack thread from last year. There was no single source of truth. Agents had no structured, permissioned way to pull org context either.

Once knowledge becomes uploadable, PHI risk shows up immediately. I added PII/PHI scanning to Ayin Wiki so someone can’t casually drop protected data into the corpus. The design problem after that was making the gate fail closed on real PHI without blocking every technical doc that mentions a URL, version string, or system name.

Research

  • Internal knowledge-worker interviews
  • Corpus and scanner false-positive review
  • Role mapping (reader / creator / admin / agent)
  • Ingest-mode experiments
  • Pilot sampling (time-to-answer)
Participants
Technical writers, eng, ops knowledge workers; security-minded stakeholders on PHI
Constraints
Must block PHI on upload; fail closed; still usable for technical writers and eng docs

I mixed “where do you actually find the answer?” interviews with a hard look at the corpus and how a first-pass scanner behaved on technical writing. That feedback shaped the two-stage PHI gate: catch real PHI, don’t punish legitimate ops and eng content.

Role mapping clarified four surfaces: readers, creators, admins, and agents via MCP. Ingest-mode experiments (rewrite vs format-only) came straight from creators who refused to let a cheap model “improve” careful markdown. In the pilot we sampled median time to a trusted snippet before vs after wiki search / Ask AI.

What I owned

End-to-end product design for the Quasar SPA (reader, creator, admin), the ingest and regen mental models, and the agent path: an MCP server people can connect from their own tools, with Okta so access is identity-bound. I also designed the bridge to an LLM-ready Figma design system so AI-assisted projects start with the same tokens and components as human-built product UI.

Approach

One corpus for people and agents: gate PHI on the way in, Okta on the way out (app and MCP).

Hypothesis: one corpus, two audiences (people in the app and agents on MCP), with upload-time PHI protection and authenticated agent access—not a shared open socket. Goal: faster trusted answers, no casual PHI in the wiki, and a way for individuals to wire their own agents in under Okta.

Product model

  • Readers browse, search, and cross-link structured markdown pages.
  • Creators upload raw docs, pick an ingest mode, trigger regeneration.
  • Admins own prompts, models, categories, quality, workspaces, members.
  • Agents hit the same pages through an MCP server I built, with tools like wiki.search, wiki.getPage, and wiki.listCategory.

MCP server + Okta

The wiki SPA is signed in with Okta—same identity plane as the rest of how people access Ayin. “Ask AI” in the app is for someone already in that session. That wasn’t enough for how teams work with agents, so I built an MCP server on the same corpus: point Claude, Cursor, or another MCP client at Ayin Wiki and pull structured pages without inventing a second knowledge base.

MCP access uses Okta as well, so the agent runs as a real person (or a service identity our org already manages). Permissions and audit stay tied to who connected—same story as human readers in the SPA.

  • Same truth: MCP tools read the same structured pages the SPA shows. No “agent corpus” that drifts from what humans approve.
  • Same identity: Okta for the browser app and for MCP clients. You’re connecting your agent under our org’s identity, not anonymous scraping.
  • Discoverable tools: search, get page, list category—enough for grounded answers and navigation without dumping the whole wiki into context by default.
  • Transport: HTTP + SSE for MCP clients that need a durable remote server, not only a local stdio toy.

The product story for hiring managers: this is the same pattern I design for ops AI—sources visible, human-controlled access, no black-box side channel into regulated knowledge.

Decisions that mattered

Two ingest modes

Rewrite for messy source material. Format-only for already-good markdown: body stays intact; only frontmatter, wiki-links, and related/sources append. Cheap models don’t quietly ruin careful writing.

Two-stage PHI gate

I put PII/PHI scanning on the ingest path so protected data can’t slip in with an upload. Stage one is a scanner pass (e.g. Comprehend); stage two is an LLM adjudicator only when something is flagged. Quarantine needs both stages to agree. Fail closed. Keep an audit trail. That keeps real PHI out without blocking every technical doc that looks “personal” to a naive pattern match.

Design system for LLMs

Packaging the Figma system for model consumption means Accelerator prototypes and product UIs start from the same primitives. “AI-first workflows” shouldn’t mean off-brand one-offs.

Time to find a trusted answer (internal sampling)
  • Before (drive / chat / email hunt)~22 min
  • After (wiki search / Ask AI)~6 min

Median time to locate an approved policy or procedure snippet. Sample of knowledge workers during pilot.

PHI protection vs. usable technical uploads
BeforeOpen uploadNo dedicated PHI gate on ingest
AfterFail closedScanner + adjudicator on every upload

Real PHI blocked; technical docs adjudicated, not auto-rejected

Product intent: prevent PHI in the corpus while keeping ops/eng docs shippable.

Structured Ayin Wiki page: PHI Handling Policy with breadcrumb, generated metadata, body, and accuracy feedback
Structured page: breadcrumb, generated timestamp/model, policy body, and accuracy feedback (same surface humans and MCP agents read)
Ayin Wiki uploads screen with drag-and-drop for PDF, DOCX, and other source files
Uploads: raw docs enter the regen pipeline here (where the PHI gate runs before content is trusted)

Architecture (short)

Quasar SPA → API Gateway / Lambdas → S3 raw/extracted → SQS → regen worker (Bedrock) → pages + DynamoDB. Auth is Okta for both the SPA and the MCP path—people sign into the wiki the same identity way their agents connect over HTTP+SSE.

Results

  • One path from raw upload to a human page and an agent-readable surface.
  • PHI scanning on upload so protected data can’t casually enter the corpus.
  • Two-stage adjudication so technical writers and engineers can still ship real docs.
  • An MCP server with Okta so people connect their own agents to the same approved pages.
  • A design-system-for-LLM bridge so AI builds stay on product UI language.

Why this still matters

If people and agents read different knowledge, demos lie and decisions drift. If uploads skip PHI checks, you inherit risk. Wiki keeps one corpus, a real gate on the way in, and Okta for both the app and MCP clients—so whoever’s asking, human or agent, hits approved pages under a real identity.

Stack

Vue 3 · Quasar 2 · TypeScript · AWS CDK · Okta (SPA + MCP clients) · API Gateway · Lambda · S3 · SQS · Bedrock · Comprehend · MCP (HTTP+SSE) · CloudFront

← All case studies