take a pass adding in marketing language

[matthewpeterkort]

No description provided.

[netlify]

✅ Deploy Preview for calypr ready!

Name	Link
🔨 Latest commit	7f1d29b
🔍 Latest deploy log	https://app.netlify.com/projects/calypr/deploys/6a04f452453ac20008027a24
😎 Deploy Preview	https://deploy-preview-91--calypr.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7f1d29ba16

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve top-level nav items in mobile sidebar

This selector removes every non-active top-level entry from the primary sidebar on all non-marketing pages, which breaks cross-section navigation in mobile/tablet contexts: the same stylesheet hides .md-header__nav at widths up to 960px, so users depend on the drawer/sidebar and can no longer jump to other top-level docs sections from pages under /calypr/ or /tools/. Restrict this hiding behavior to desktop-only layouts or keep all top-level items visible in the mobile drawer.

Useful? React with 👍 / 👎.

[bwalsh]

PR Review: feature/marketing-speak

Summary

This branch does a strong job repositioning the site around business-facing Products and Solutions pages. The information architecture is much clearer for non-technical readers, and the supporting styles in docs/stylesheets/extra.css are mostly consistent with the new layout patterns.

I found two review items worth addressing before merge.

---

Overall this is a solid restructuring of the site around Products and Solutions. The messaging is much clearer for non-technical readers, and the new layouts look well supported in docs/stylesheets/extra.css.

I have two review comments:

1. In docs/products/index.md, the “For technical teams” cards link directly to .md files (../tools/git-drs/index.md, etc.). Elsewhere the site uses route-style links, so these should probably be changed to canonical URLs like ../tools/git-drs/ to avoid brittle or non-canonical navigation.

2. The Manage Models → GRIP docs handoff in docs/products/index.md feels less direct than the other product/tool mappings. If this is intentional, I’d recommend clarifying the copy so readers understand why GRIP is the implementation path for that product.

Everything else looks directionally strong, especially the updated homepage framing and the use-case/buying-path structure on docs/solutions/index.md.

---

Findings / Requested Changes

1. Use canonical route links instead of direct .md links

Severity: Medium

In docs/products/index.md, the “For technical teams” section links directly to markdown source files:

• docs/products/index.md:149 → ../tools/git-drs/index.md
• docs/products/index.md:154 → ../tools/funnel/index.md
• docs/products/index.md:159 → ../tools/forge/index.md
• docs/products/index.md:164 → ../tools/grip/index.md

The rest of the site generally uses directory-style canonical routes such as:

• ../products/manage-data/
• ../products/manage-compute/
• products/

Direct .md links are more brittle and may produce non-canonical URLs depending on how Zensical publishes routes.

Recommendation

Switch these links to route-style URLs:

• ../tools/git-drs/
• ../tools/funnel/
• ../tools/forge/
• ../tools/grip/

Why this matters

• Keeps navigation consistent across the site
• Avoids relying on source-file paths in published pages
• Reduces the chance of broken links if routing behavior changes

---

2. The Manage Models → GRIP docs handoff is conceptually unclear

Severity: Medium

In docs/products/index.md:142-165, the section claims that each product “hands off to the tool docs behind it.” That mapping is clear for:

• Manage Data → Git-DRS
• Manage Compute → Funnel
• Integrate Data → Forge

But the last card maps:

• Manage Models → GRIP

Specifically:

• docs/products/index.md:162-164

The current copy reads more like GRIP provides graph/provenance context rather than a clear model-management implementation surface. That makes this mapping feel less direct than the others.

Recommendation

Either:

1. clarify that Manage Models is currently enabled through GRIP-backed graph/provenance capabilities, or
2. soften the claim that every product has a single direct underlying tool handoff

Why this matters

• Prevents readers from assuming GRIP is a dedicated model-management tool
• Keeps the product story internally consistent
• Avoids confusion during evaluation by non-technical buyers

---

Positive notes

Homepage framing is much clearer

The updated messaging in docs/index.md gives the site a more focused business-facing front door:

• docs/index.md:10-25
• docs/index.md:81-101

Solutions page has a strong decision flow

The structure in docs/solutions/index.md is effective and easy to follow:

• use cases: docs/solutions/index.md:70-127
• operating path: docs/solutions/index.md:129-160
• buying paths: docs/solutions/index.md:163-210

Responsive CSS appears to cover the new layouts

The new grids and cards appear to be handled consistently in docs/stylesheets/extra.css, including responsive collapse behavior:

• docs/stylesheets/extra.css:805-865
• docs/stylesheets/extra.css:867-914
• docs/stylesheets/extra.css:1000-1073
• docs/stylesheets/extra.css:1576-1594

---

[bwalsh]

We should brainstorm this figure:

[bwalsh]

We should brainstorm these "cards within cards"

[bwalsh]

We should brainstorm the name data_client

[bwalsh]

See comments