Retrospective

How I Write About Confidential Work Without Making It Empty

07/13/2026 · 5 min read · Working note

• Portfolio
• Confidentiality
• Technical Writing

Created and reviewed on July 13, 2026. This note describes my public writing rules, not legal advice.

One of my work experiences involved a Marine Food Inspection Program. I worked on software development and project coordination, but the project included confidential information.

This creates a common portfolio problem. If I say too little, the experience looks empty. If I say too much, I may expose information that is not mine to publish.

My answer is to explain my responsibility and the general technical flow, while leaving out protected details.

What I can explain

I can describe the type of work I did.

My responsibilities included:

• preprocessing data from vision and spectral cameras;
• reading technical documents and using a provided library for a camera-specific preprocessing flow;
• handling AI output after inference;
• converting processed results into data for browser display;
• delivering the data through an API in near real time;
• writing project documents and coordinating schedules and field work.

This tells a reader what I can do. It does not require the internal dataset, exact model setup, or a private screen.

I can also explain the flow at a high level:

Camera data
  -> preprocessing
  -> AI inference
  -> result post-processing
  -> browser-ready data
  -> API delivery

The flow is useful because it shows the connection between hardware data, model output, backend processing, and the final user screen.

What I do not publish

I do not publish:

• partner or customer names;
• the exact confidential project title;
• internal reports or presentation pages;
• private screen captures;
• sample datasets;
• model configuration details;
• performance numbers that are not approved for public use.

I also do not assume that an image is free to reuse because it is visible on another company’s blog. Public access and reuse permission are different things.

When I need a visual, I can use a simple original diagram that explains my own workflow. I should label it as a concept diagram, not as a real project screen.

Contribution is stronger than secret detail

A good case study does not need every technical secret. It needs a clear answer to four questions:

1. What kind of problem did the team work on?
2. What part did I own or perform?
3. How did data move through my part of the system?
4. What did I learn or improve?

For this project, the useful story is not the name of the partner. It is that I could read unfamiliar camera documentation, build preprocessing and post-processing steps, connect the result to an API, and also coordinate practical project work.

That combination shows both technical work and responsibility.

Evidence needs a clear label

I separate three kinds of visual material.

Real project evidence is material that I created or have permission to show. It must still be checked for private data.

Public reference material belongs to its original source. I can link to the source, but I should not copy it into my portfolio without checking the reuse right.

Concept material is an original diagram made to explain a general process. It must not look like proof of a real internal screen.

This labeling protects the project and also makes my portfolio more honest.

The wording I use

I use direct language about my work:

I implemented camera-data preprocessing, AI-result post-processing, browser-ready data conversion, and API delivery. I also handled documentation and project coordination. Internal project details are limited because of confidentiality.

I avoid weak wording that hides my contribution. I also avoid strong claims that I cannot prove.

The goal is not to make confidential work sound mysterious. The goal is to show a real working process with a clear boundary. That is part of technical communication: explain enough to be useful, and stop before the explanation becomes disclosure.