Selected case study
Report 02 / Business-model knowledge library
Live knowledge product with reviewed content, figures, and resources.
02
Business-model knowledge library
A knowledge product for business models, decision frameworks, metrics, templates, and practical operating resources.
A knowledge product has to help people choose, not just browse.
The product bet was that business frameworks become more useful when they are organized around decisions, constraints, questions, visuals, and practical outputs.
Decision path
The job is not collecting models. It is helping a reader find the right model for the decision.
The corpus became a generated product surface.
The rebuilt app turns a canonical corpus into routes, search indexes, article pages, visual components, templates, packs, and account-aware library surfaces.
Generated surface
The product is a content operating system, not a static article archive.
Source fidelity became the quality bar.
The review system separates source-faithful figures, generated diagrams, article formatting, internal links, public previews, and protected working files so the product does not publish plausible-but-wrong knowledge.
Review gates
AI-assisted production only works when the acceptance criteria are more rigorous than the generation.
The operating loop is a reviewable ledger.
The strongest product evidence is the machinery around the site: editorial queues, formatting review, figure review, internal-link audits, resource checks, and generated snapshots.
Quality loop
The product keeps improving because the work leaves a system behind it.
A large personal knowledge corpus can become valuable but hard to trust: different formats, uneven depth, visual inconsistency, source ambiguity, and hundreds of models that are difficult to choose from when a real decision is at stake.
A business-model knowledge product with searchable records, article pages, semantic visuals, templates, packs, saved-library paths, protected resources, and an editorial QA workflow backed by a durable review ledger.
That I can turn accumulated knowledge into a product system: information architecture, source fidelity, template productization, visual treatment lanes, review states, and growth loops rather than a static archive.
01 / Builder signal
Key Models shows how I turn a large body of strategy knowledge into a usable product system: corpus architecture, generated routes, article reading experience, semantic diagrams, templates, source boundaries, internal linking, and review workflows.
Key Models started from years of accumulated business frameworks, diagrams, notes, and resources. That history is the value, but it is also the product challenge: material collected over time rarely arrives with one taxonomy, one source standard, one visual grammar, or one quality bar.
The product work was therefore not just publishing content. It was deciding how a reader should enter the corpus, how models should be classified, what makes a source authoritative enough, when a visual should be coded and when the original image preserves meaning better, and how hundreds of review decisions stay durable.
The case is a different kind of proof from the SaaS products. It shows information architecture, editorial operations, semantic visual judgment, template packaging, and a review system that keeps quality from living only in memory or chat.
02 / Product evidence
Screenshots selected as product evidence, not decoration.
Curated live-product captures, cropped for readability so the product proof stays inspectable.
The product starts with the reader’s decision context, not with a raw encyclopedia of frameworks.
Counts, categories, templates, and model types make the size of the corpus legible without asking the reader to browse everything.
Templates and resources turn framework knowledge into something a user can apply, edit, and return to.
The article system can render model-specific visuals while preserving the decision structure the reader needs.
Templates create a product layer beyond reading: previews, guidance, editable files, and resource packaging.
A review dashboard tracks pages, fixes, status, article previews, and review notes so quality is operational.
03 / Strategy choice cascade
This section is the product-management read: who the product is for, where it starts, how it can win, what capabilities matter, and how the work keeps learning.
Become an operating library for better business decisions, not just a framework encyclopedia.
Operators, founders, strategists, consultants, and teams who need practical decision tools.
Combine searchable model knowledge, semantic visuals, templates, packs, source boundaries, and reviewable quality systems.
Next.js app, generated corpus projections, article renderer, semantic visual registry, search facets, templates, and account-aware resources.
Editorial ledger, figure review, formatting QA, internal-link audits, source checks, protected-resource boundaries, and generated snapshots.
04 / Product map
Solo product builder across product strategy, information architecture, corpus migration, visual system, article UX, template productization, QA workflows, and full-stack implementation.
05 / Product-risk model
The risk map shows what had to be true before the product could be treated as more than a concept.
Records are organized by question, category, model kind, domain, complexity, horizon, and decision level.
Search, filters, article rails, metadata, related links, and diagrams reduce the burden of browsing a large corpus.
The repo uses generated registries, route maps, source boundaries, visual registries, and validation scripts.
Templates, packs, saved library, pricing surfaces, account access, and protected resources create product depth beyond articles.
The local review ledger tracks reviewed pages, figures, resources, formatting issues, source checks, and remaining work.
The strongest Key Models decision was refusing a technically convenient answer when it damaged meaning. A bulk SVG conversion could satisfy a build request while losing labels, relationships, sequence, or the point of the original figure.
That turned into a broader rule: formulas, tables, charts, diagrams, documents, and illustration-dependent assets need different treatment lanes. Source fidelity became the acceptance criterion, and the review ledger became part of the product rather than an internal chore.
06 / Product learning stories
Interview-grade product stories: what was ambiguous, what I chose, and what the product learned from that decision.
07 / Method bridge
Each flagship case shows the same pattern: use AI for leverage, keep judgment human, reduce product risk, and leave an operating loop behind the product.
The work depends on product briefs, real-codebase context, implementation review, validation checks, and careful claims rather than one-off prompting.
The case reduces the major product risks while making the trust surface explicit: value, usability, feasibility, viability, and launch confidence.
The next step is better evidence: user behavior, pilot feedback, operational checks, security posture, and roadmap decisions.
08 / Operating loop
09 / Trust layer
10 / What this shows