← Book Production Lab Cambric Book Production Lab · Product evidence
See what Cambric demonstrates today—and where we keep the claim narrower.
A public register separating the current Cambric product model and documentation from claims that still require reproducible import fixtures, export specimens, or independent validation.
CambricDOCX source translation LOCAL
TRANSLATION LEDGER
✓
Character emphasisBold · italic · small caps
MAPPED✓
FootnotesAnchors and note content
MAPPED✓
Inline imagesSource assets retained
PRESERVED!
Custom tab stopParagraph 118
REVIEWCambricEdition profiles LOCAL
⌘
Maintained manuscript24 chapters · source current
SHARED CONTENT Use this when you need to
Make the production decision explicit.
- Evaluate Cambric without relying on vague feature adjectives
- Separate visible workflow evidence from export validation
- Track the next proof assets the product should publish
- Give search and answer engines a stable first-party claim boundary
Open dataset
Download JSON Cambric Workflow Evidence Register
Each row separates the current first-party product model and documentation from the stronger artifact, device, or customer evidence still required. Fresh code-native demonstrations explain the workflow; they are never presented as screenshots or as proof that an arbitrary manuscript will pass every destination.
| Capability | Public evidence | Supported claim | Claim boundary | Next proof asset |
|---|---|---|---|---|
| Source-preserving DOCX import | Current product tour, purchase FAQ, and source-translation demonstration document an immutable original package, checksum, styles, relationships, assets, warnings, and translation ledger | Cambric is designed to keep the original DOCX recoverable while supported content becomes editable | Does not claim pixel-identical Word rendering or lossless editing of every DOCX feature | Versioned complex-DOCX fixtures with expected translation ledgers |
| Semantic manuscript model | Current product tour documents volumes, parts, chapters, sections, front matter, back matter, notes, images, tables, poetry, letters, and special blocks | Cambric represents book elements by meaning instead of treating editor JSON as the complete product model | The presence of an element type does not prove perfect handling of every manuscript instance | Public test manuscript covering every supported semantic element |
| Cascading design rules | Current formatting demonstration documents edition defaults, element-type rules, individual overrides, and format-specific overrides | Cambric resolves professional book design through an inheritance model with explicit exception layers | Does not imply every visual property is independently customizable | Screen recording showing effective-value provenance across a real chapter |
| Edition profiles | Current product demonstration shows one maintained manuscript feeding distinct print, ebook, and editable DOCX profiles | Cambric separates shared content from edition- and format-specific presentation decisions | Does not claim print layout can or should be reproduced identically in a reflowable ebook | Matched edition package generated from one public source manuscript |
| Release preflight | Current product tour separates blocking issues, advisory reviews, and passed checks before generation | Cambric is designed to surface output-specific release risk before file generation | Preflight cannot guarantee retailer acceptance or replace physical proof review | Versioned preflight report paired with generated artifacts |
| PDF, EPUB 3, and editable DOCX output | Current product and purchase documentation identify the three output paths and their different jobs | Cambric generates fixed print, reflowable ebook, and editable manuscript handoff formats from the maintained project | No blanket claim that every unusual asset or destination transformation is lossless | Downloadable PDF, EPUB, DOCX, validation, and source bundle |
| Local-first projects | Product and policy copy consistently describe local working projects | Working manuscript projects live on the user’s machine | Purchase, licensing, download, and update services can use the internet | Storage and backup documentation |
| Windows and macOS builds | License-protected download workflow lists 64-bit Windows, Apple Silicon, and Intel Mac | Desktop builds are distributed for those targets | Compatibility still depends on supported OS versions and hardware | Public system-requirements table with tested versions |
Limitations
- Code-native product demonstrations explain intended workflow and relationships; they are not screenshots of a customer project.
- This register is not a substitute for a reproducible import/export specimen, screen recording, or customer case study.
- Output-conformance and source-fidelity claims remain bounded until versioned artifacts and validator reports are published.
Why a software company should publish its claim boundary
Marketing pages often collapse several different ideas into one sentence: a product model contains an export path, the export produces a file, the file conforms to a specification, and every retailer accepts every manuscript. Those are not the same claim. A code-native demonstration can explain workflow and relationships. A screen recording can show the running product. A versioned output plus validator report can demonstrate properties of that sample. A customer case study can document one real production outcome. Only the destination decides whether a submitted title is accepted.
This register keeps those layers separate. Each capability lists the public evidence available, the statement that evidence supports, the boundary we will not cross, and the next stronger proof asset. That makes the website less reliant on unsupported superlatives and gives buyers a clearer basis for comparison. It also creates a product-marketing backlog: the missing evidence is visible instead of being papered over with copy.
What the current product demonstration establishes
The current demonstration maps the actual product shape: an immutable imported DOCX alongside an editable semantic book model; design inheritance from edition defaults through element and format overrides; one manuscript feeding print, ebook, and editable handoff profiles; and preflight separating blockers from advisory review. The product tour labels the visuals as demonstrations rather than pretending they are customer screenshots.
Those are meaningful buying facts because they let an author judge whether the operating model fits the job. They do not establish how every DOCX imports, how every font behaves, or whether an arbitrary illustrated manuscript passes a retailer. The purchase page says that plainly. A buyer gets a 30-day guarantee to test the actual workflow rather than being asked to treat a marketing visual as proof of every possible result.
The evidence assets that matter next
The most valuable next asset is not another generic blog post. It is a versioned specimen package: a public DOCX test manuscript, import and translation ledger, recording of the composed result, exported print PDF, EPUB and editable DOCX, a PDF preflight record, and an EPUBCheck report. That package would let an author inspect the output and let technical reviewers reproduce the claims.
The next layer is real customer evidence with permission: project type, manuscript constraints, workflow before Cambric, time or error reduction, released formats, and a public artifact where possible. We will not manufacture those stories. Until permission and evidence exist, the site should use product demonstration, transparent limitations, and the refund window instead of fake testimonials or anonymous numerical claims.
How this strengthens organic growth
Search engines and answer systems need stable, first-party facts they can retrieve and reconcile. A structured register with dates, explicit capabilities, and limitations is easier to cite than a collection of pages making inconsistent claims. It also reduces leakage on comparison pages: Cambric can argue from its own evidence rather than building the competitor’s feature narrative. The product remains the subject, and external platforms appear only where their submission rules define the buyer’s job.
Evidence also improves conversion quality. A high-intent visitor wants to know whether the tool runs on their computer, fits their kind of book, keeps control of the source, and produces the required output types. Answering those questions precisely is more persuasive than repeatedly saying “professional.” The register turns proof into an acquisition asset and gives future release work a clear place to land.
Apply the research
Evaluate the complete Cambric workflow with a real manuscript.
The public register defines the fit; the 30-day guarantee lets a buyer verify the workflow on their own book. Cambric is a local-first Windows and Mac production system with retained DOCX source, controlled editions, preflight, PDF, EPUB, and editable DOCX output paths.
Review Cambric for my manuscript $199 once · Windows + Mac · local-first projects · 30-day guarantee Questions this resource answers
Production FAQ
Does Cambric guarantee acceptance by KDP or another retailer?
No. Cambric exports print PDF and EPUB 3, but platform rules change and manuscripts vary. Inspect and validate the actual artifacts, use platform previews, and order a print proof.
What evidence is currently public?
Fresh first-party product-model demonstrations, workflow documentation, system/build information, output-path documentation, and this versioned claim register are public. Reproducible import/export specimens, recordings, and customer case studies are the next evidence milestones.
Why publish limitations on a sales site?
Clear qualification increases buyer confidence and reduces poor-fit purchases. It also prevents a demonstration or feature label from being misrepresented as broader technical proof.