A case study can be accurate sentence by sentence and still leave the wrong impression.
“Built for a client” can sound like “deployed across the client’s organization.” A working repository can sound like a released product. A public link can suggest ownership. A polished interface can imply adoption. None of those inferences needs an outright false statement. They appear in the space between facts that have been allowed to blur together.
JodyInk uses four separate questions before writing a public case: What was the relationship to the work? What was implemented? What is available now? What outcome can be supported?
The questions are simple. Keeping their answers separate is the harder product decision.
Relationship does not establish reach
A client engagement establishes a commercial relationship. It does not establish organization-wide use, a public launch, or a measured business result.
One JodyInk engagement involved inconsistent operational records. A Python utility normalized names, placed original roles beside proposed mappings, and flagged complex names and unmapped roles in a review sheet. That is enough to describe meaningful work: the problem was real, the transformation existed, and the review boundary was implemented.
It is not enough to claim scale, time saved, adoption, or an enterprise platform. Those would require different evidence and, for private work, permission to publish it.
The useful case is therefore not “JodyInk transformed enterprise operations.” It is operational data prepared for review, with the client unnamed and the mechanism visible. The constraint does not make the work smaller. It makes the claim precise.
Implementation does not establish availability
Software can be substantial before it is publicly available.
SceneArc implements semantic retrieval and model-assisted composition around user-owned observations. CutSeen reconstructs viewing history, previews imports before writing them, and retains recovery paths. Both contain real product and engineering decisions. Neither needs to be described as launched merely because the code works.
This distinction improves the case. “In development” gives the reader the right frame for what follows. They can evaluate the domain model, the safeguards, and the product judgment without having to wonder whether a missing signup link is an oversight.
Availability is its own field because it changes independently. A product may move from private to public without changing the implementation described in the case. The record should be able to state that change without rewriting its history.
A public artifact does not settle attribution
Public evidence creates a different trap. If a studio links to an artifact, readers may assume the studio owns, publishes, or operates it.
Amicus Index exposes a public evidence framework that distinguishes fact, pattern, analysis, and speculation. It is relevant to JodyInk because the framework demonstrates a method the studio values: a reader should be able to see what kind of statement is being made. The public case can point to that artifact and explain the distinction.
It should not silently convert relevance into ownership. Neutral attribution preserves what the public source establishes and no more. The link remains useful because the framework can be inspected directly.
This is also why a logo grid is often a poor substitute for case writing. Proximity does too much unspoken work. A named relationship is less glamorous and more informative.
Outcome needs its own evidence
Implemented behavior can support a product consequence without supporting a business outcome.
Keeping an original field beside a proposed update makes a transformation reviewable. Reconstructing a rewatch as a separate history prevents the second viewing from overwriting the first. Restricting generated citations to a supplied evidence set makes a reference boundary inspectable.
Those are consequences of the design. They can be shown in code, tests, or a working artifact.
They are not the same as faster delivery, fewer errors in production, improved retention, or better decisions. Those claims require observation beyond the implementation itself. When that observation does not exist, a case does not need a decorative Results section. It can end with what the product now permits and where verification still belongs.
Polish does not cure an unsupported claim
The tempting alternative is a familiar case-study arc: challenge, solution, impact. It is easy to scan and easy to sell. It also pressures every project into a finished success story, even when the most interesting work is a careful boundary or a decision made before release.
A more accurate case can still have shape. Start with the condition that made the work necessary. Name the consequential choice. Show what was implemented. State the present boundary. Link to a public artifact when one exists.
The difference is that the structure follows the evidence instead of demanding an outcome on schedule.
A release check for public work
Before a case goes live, read it once for facts and once for implications.
On the factual pass, identify the source for each concrete statement. A repository proves implementation, not use. A plan proves intent, not completion. A client relationship proves the engagement, not a result.
On the implication pass, ask what a hurried reader will probably conclude. Would they think the product is available? That the studio owns the linked publication? That a private client approved the description? That a deterministic rule is AI? That an implemented guard guarantees a correct answer?
If the likely inference outruns the evidence, the answer is not always more qualification. Often the sentence needs a narrower subject. “The utility preserves the original value” is clearer than “The workflow builds trust.” The first statement can be inspected. The second asks the reader to supply the proof.
The purpose of this discipline is not defensive writing. It is to make the actual work legible. A case becomes more credible when relationship, implementation, availability, and outcome each carry only their own weight.
The JodyInk work index applies the distinction across public brands, studio developments, and anonymous client engagements.