Azure Blob Photo Ledger Naming for Construction Teams

Construction site photos become hard to trust when every phone upload keeps a name like IMG_4821.jpg. The blackboard may show the project number, the chat thread may include a note from the site supervisor, and the final handover packet may need only roof waterproofing photos. But once the files land in Azure Blob Storage without a naming rule or tags, the team spends another afternoon asking who took which photo. The first fix is not a new app. It is a small photo-ledger rule for blob names and tags.

This article shows how a construction company can use Claude Code to review Azure Blob Storage naming, Blob index tags, metadata, SAS sharing, soft delete, versioning, and lifecycle notes before the archive grows. For public case-study pages, see construction case study pages with Claude Code. Here the focus is internal search and handover readiness.

Key Points

• Construction photos should not rely on the camera filename. Separate project ID, phase, location, status, date, and sequence.
• Azure Blob names are flexible, but container names have stricter rules. A naming table avoids late cleanup.
• Blob index tags are useful for finding photos later. Metadata is better for supporting notes that do not need indexed search.
• Claude Code can draft a naming rule, required tags, CSV columns, and sharing checklist from a sample folder.
• Humans still review customer names, addresses, faces, license plates, accident photos, contracts, publication approval, and deletion requests.

Where The Photo Ledger Breaks

A construction photo ledger receives files from phones, LINE, email, shared folders, subcontractors, and project management tools. At handover time, the team needs proof photos for waterproofing, reinforcement, repair-before, repair-after, inspections, or insurance. If the blob is named IMG_4821.jpg, the storage account has the file but the office cannot find it quickly.

The expensive problem is not always missing photos. It is hidden context. The project number is on a blackboard, the phase is in a chat message, the photographer is in the phone owner, and the requested packet is in an email. If none of that becomes the blob name, Blob index tags, or ledger CSV, the team reopens chat history and resends the same files. Even fifteen extra minutes per request becomes painful at month end.

Primary references checked for this article include Azure Blob Storage introduction, container and blob naming rules, Blob index tags, lifecycle management, soft delete, and SAS overview.

Workflow: Turn Photos Into Searchable Records

Start from the photo list, not from the Azure Portal. Put project ID, shot date, phase, location, photographer, destination, and publication status into a simple table. Then decide what belongs in the blob name, what belongs in Blob index tags, what belongs in metadata, and what stays only in the human-reviewed CSV.

Place	Example	Why it exists	Human review
Blob name	2026/07/site-042/waterproof/20260719_roof_before_001.jpg	sorting and visible sanity check	avoid customer names in URLs
Index tags	projectId=site-042, phase=waterproof	search and extraction	tag spelling drift
Metadata	shotBy=staff-01, source=line	supporting import history	people and contact data
Ledger CSV	URL, phase, submission target, approval	handover review	faces, license plates, addresses

Claude Code can read a sample table and return a candidate path such as projectId/yyyy/mm/phase/location/date_status_seq.ext. The point is not to stuff every fact into the file name. Keep the name short enough to scan, then put searchable facts into tags and review decisions into the CSV.

What Claude Code Does and What Humans Decide

Claude Code drafts the naming rule, required tags, missing-field checks, CSV columns, sharing checklist, and retention notes. Give it the current folder, a hundred file names, project number rules, phase names, submission targets, and the current upload path. It can return a table that a site supervisor and office staff can review together.

Humans decide the content risk. Customer names, addresses, faces, license plates, neighboring homes, accident photos, contract documents, public approval, and deletion requests must remain human decisions. Claude Code can flag suspicious names and empty tags, but it should not mark a real construction photo as publishable.

SAS sharing also needs a human boundary. For temporary photo review, prefer read-only access, short expiry, and a limited blob or prefix rather than a whole container. For long-term storage, review soft delete, versioning, and lifecycle policies separately.

3 Use Cases

Use case 1: Create a site-photo naming rule

• Input: existing folders, photo names, project IDs, phases, locations, shot dates, submission targets.
• Output: blob name template, sequence rule, banned words, spelling dictionary, CSV columns.
• Human review: customer names, addresses, and site names that should not appear in URLs.

Use one recent site and sample one hundred photos. Put the current name, shot date, phase from the blackboard, location, and destination into a table. Claude Code drafts the naming rule. Humans remove sensitive labels before upload.

Use case 2: Make the ledger searchable with Blob index tags

• Input: projectId, phase, location, status, shotDate, submittedTo, publicOk.
• Output: tag design, search examples, required tags, empty-field rule, spelling dictionary.
• Human review: no customer names, addresses, phone numbers, or license plates in tags.

Blob index tags help the team find photos later. A query for projectId=site-042 and phase=waterproof is much easier than searching camera names. Keep the tag values short and internal.

Use case 3: Review shared URLs before sending them

• Input: photos to share, recipient, expiry, permissions, email text, submission deadline.
• Output: SAS note, expiry checklist, share list, send-before checklist.
• Human review: recipient, read-only permission, expiry, people in photos, contract details.

Shared URLs reduce back-and-forth, but a broad URL can leak too much. Claude Code can turn the URL list into a review table. Humans check that the link is not container-wide, write-enabled, too long-lived, or mixed with accident and repair photos.

Copy-Paste Prompt

Act as a construction photo ledger reviewer.
Goal: make Azure Blob Storage photos searchable without exposing customer or site-sensitive data.

Input:
- current folder and file names
- project ID, phase, location, shot date, submission target
- proposed Blob Storage container
- sharing URL workflow
- retention notes

Check:
1. blob names include project, date, phase, location, status, and sequence
2. customer names, addresses, people, and license plates are not placed in URLs or tags
3. Blob index tags and metadata have separate purposes
4. shared URLs are read-only, short-lived, and narrow in scope
5. soft delete, versioning, and lifecycle notes exist
6. a ledger CSV lets humans approve publication

Return:
- naming rule
- required tag table
- ledger CSV columns
- risky file-name examples
- a 100-photo first review plan

Working Check Code

// verify-construction-photo-ledger.mjs
// No dependencies. Run with: node verify-construction-photo-ledger.mjs
const photos = [
  {
    blobName: "IMG_4821.jpg",
    tags: { projectId: "site-042", phase: "waterproof" },
    metadata: { source: "line" },
    share: { permission: "read", expiresInHours: 240 }
  },
  {
    blobName: "2026/07/site-042/waterproof/20260719_roof_before_001.jpg",
    tags: {
      projectId: "site-042",
      phase: "waterproof",
      location: "roof",
      status: "before",
      publicOk: "review"
    },
    metadata: { source: "camera", shotBy: "staff-01" },
    share: { permission: "read", expiresInHours: 24 }
  },
  {
    blobName: "sato-home-address-kyoto-crack-after.jpg",
    tags: { projectId: "sato-home", phase: "repair", publicOk: "yes" },
    metadata: { customerName: "Sato" },
    share: { permission: "write", expiresInHours: 72 }
  }
];

const requiredTags = ["projectId", "phase", "location", "status", "publicOk"];
const blobNamePattern = /^\d{4}\/\d{2}\/[a-z0-9-]+\/[a-z0-9-]+\/\d{8}_[a-z0-9-]+_(before|after|progress)_\d{3}\.(jpg|jpeg|png)$/i;
const sensitiveWords = /(address|customer|home|name|phone|car|license|住所|氏名|電話|車番)/i;
const problems = [];

for (const photo of photos) {
  if (!blobNamePattern.test(photo.blobName)) {
    problems.push({ blobName: photo.blobName, item: "blob name", fix: "use yyyy/mm/project/phase/date_location_status_seq.ext" });
  }
  for (const tag of requiredTags) {
    if (!photo.tags[tag]) {
      problems.push({ blobName: photo.blobName, item: `missing tag: ${tag}`, fix: "fill required Blob index tags before upload" });
    }
  }
  if (sensitiveWords.test(photo.blobName) || sensitiveWords.test(JSON.stringify(photo.tags)) || sensitiveWords.test(JSON.stringify(photo.metadata))) {
    problems.push({ blobName: photo.blobName, item: "sensitive label", fix: "remove customer names, addresses, phone numbers, and car identifiers" });
  }
  if (photo.share.permission !== "read") {
    problems.push({ blobName: photo.blobName, item: "share permission", fix: "use read-only sharing for external photo review" });
  }
  if (photo.share.expiresInHours > 48) {
    problems.push({ blobName: photo.blobName, item: "share expiry", fix: "shorten SAS expiry for temporary construction photo review" });
  }
}

if (problems.length > 0) {
  console.table(problems);
  process.exitCode = 1;
} else {
  console.log("Construction photo ledger checklist passed.");
}

The script checks blob names, required tags, sensitive labels, share permissions, and share expiry. In real work, humans still inspect faces, license plates, neighboring homes, contracts, and publication approval.

Pitfall: Common Failure Cases

The first failure is trying to put every fact into the filename. The cause is skipping the split between blob name, tags, metadata, and ledger CSV. The fix is to keep the blob name short and put searchable fields into tags.

The second failure is putting private details into tags. Use internal project IDs instead of customer names or addresses.

The third failure is a long-lived or broad shared URL. Set read-only access, a short expiry, and the smallest target that works.

The fourth failure is ignoring deletion and retention. Handover photos, warranty photos, accident photos, and temporary chat imports do not need the same retention rule.

FAQ

Q. Can all photos live in one container?

A. Often yes at the beginning. If public photos, internal photos, accident photos, and long-term archives need different permissions or retention, compare containers or prefixes.

Q. What belongs in tags instead of metadata?

A. Put searchable keys in Blob index tags: projectId, phase, location, status, and publicOk. Put supporting import history in metadata.

Q. Are SAS URLs safe?

A. They can be safe for temporary review when the permission is read-only, the expiry is short, and the target scope is narrow.

Q. What should a team do today?

A. Pick one recent site and check one hundred photos for blob name, projectId, phase, location, status, and publicOk.

Training And Consultation Signal

For monetization, measure search time, resend requests, empty CSV fields, photos stopped before submission, expired shared links, and inquiry rate. If those numbers are painful, photo ledger design, Blob Storage permissions, and publication workflow are a good fit for ClaudeCodeLab training.

What I Verified

I checked Microsoft Learn pages for Blob Storage introduction, naming rules, Blob index tags, lifecycle management, soft delete, and SAS. I also checked the slug, frontmatter, internal link, external links, CTA, executable JavaScript, locale coverage, and queue removal.