Summary
An external file arriving in storage is evidence that something was observed. It is not evidence that the file is the current, relevant, or authoritative document for an operational workflow. In preconstruction, confusing those two events creates a quiet but expensive failure mode: downstream work starts from a file that looks available but has not earned the status of canonical project-document truth.
LKCI's document-publication workflow makes the decision explicit. It observes candidate files, classifies and compares them, resolves document family and precedence where it can, preserves provenance, and creates reviewable issues where it cannot. The aim is not to make ingestion ceremonious. It is to prevent a transport event from becoming a business decision by accident.
Operational Tension
Portal, mailbox, and staged-file sources can yield duplicates, revisions, unchanged files, incomplete packages, and files whose role is unclear. A simple pipeline can download all of them successfully. From a file-transfer perspective, that is success. From an estimator's perspective, it is not yet useful: which document belongs in the opportunity corpus, which version should shape sizing or an RFI, and what should happen when two plausible sources conflict?
Treating every download as published forces the next consumer to rediscover these questions. Different consumers can reach different answers, and neither answer may retain the reasoning. Treating every incoming file as a manual queue has the opposite failure: automation captures evidence but cannot move ordinary work forward. The design problem is to automate the determinate cases without turning ambiguity into false certainty.
Decision: Publish A Governed Corpus
The workflow separates observation, storage, and publication. Publication services determine relevance, resolve semantic families, compare current and unchanged candidates, apply precedence, write versioned opportunity-owned document state, and trigger downstream work only after that state exists. Storage supports the artifact lifecycle; it is not the authority that says an artifact is ready for estimating.
Precedence is the critical middle step. The existing case-study and workflow sources describe ranking candidates using characteristics such as family, freshness, scope, classification, and evidence quality. Those factors are not presented as a universal document algorithm. They are a domain policy that makes the rule visible enough to test and revise. A candidate may become the current published document, remain unchanged, need reclassification, or create a review issue.
This yields an intentionally modest claim: a published document is a controlled internal record with provenance and a declared relationship to its source. It does not mean that the content is complete, correct for every use, or free of later supersession.
Failure And Repair Posture
Ambiguity is a first-class outcome. When a service cannot resolve a family or precedence safely, it should not choose by incidental arrival order, overwrite an existing record silently, or ask a later consumer to infer what happened. It records a reviewable issue with the evidence needed to decide.
That posture matters after repair as well. A human reclassification or precedence choice should update the durable workflow state, not merely fix a local download. The corpus then has a coherent basis for downstream indexing, sizing, RFI context, and estimator review. A subsequent run can compare against that state rather than recreate the dispute from an unstructured pile of files.
The architecture also distinguishes expected ambiguity from programmer or infrastructure failure. A malformed policy, authorization failure, or violated invariant should fail visibly. A plausible but unresolved document relationship is operational data. Combining them behind a blanket catch would make both repair paths worse.
Tradeoff
Publication adds policy, durable state, and a possible review step before downstream processing. That can delay a document relative to a direct download-to-index shortcut. It also makes the implementation more demanding: precedence rules need tests; provenance must be preserved; unchanged and superseded paths must be explicit.
The alternative moves that cost outward. Estimators, sizing logic, and RFI workflows would each need their own ad hoc answer to “which file counts?” The result might look faster until a conflicting revision or ambiguous family appears. Centralizing the publication decision makes the delay visible at the right boundary and lets all later consumers rely on the same corpus.
Limits
This pattern does not guarantee that an external source supplies complete or truthful documents. It does not replace domain judgment about plans, scope, or bid strategy. It also should not be generalized into a single global publication table for unrelated workflows; document semantics remain domain-owned. The public account intentionally omits source-specific examples, customer context, and operational counts.
Transferable Lesson
When an external artifact can influence later decisions, define a publication boundary between “we received it” and “the system may rely on it.” Make the criteria and provenance durable; make the ambiguous path repairable; and let consumers use the published record rather than inventing their own authority. That principle applies equally to files, imported records, model-extracted evidence, and analytical datasets.