HARBOR Initiative LLC
Capability statement
Requirements provenance, governed AI, federal data
4 November 2026 · Amyn Porbanderwala, Founder and Principal, HARBOR Initiative LLC
HARBOR Initiative LLC · UEI K4CVRY71WQZ8 · CAGE 260D0 · SAM.gov Active · Missouri City, Texas
Requirements, traced.
How HARBOR turns requirements documents into a validated model that records its source, method and confidence, and the two products built on the same discipline: Helm and HARBOR Port.
SAM.gov Active · UEI K4CVRY71WQZ8 · CAGE 260D0 · NAICS 541512 (opens in new tab)
The problem
A plausible model is not a traceable one.
Requirements do not arrive as data. In the documents we read, they arrive as documents.A requirement set is a specification, a spreadsheet, a tool export or a package of documents. Each carries the same requirement in another shape, and the links between requirements live in the tool that produced them. The documents say what a requirement is; they do not define a common data model for it. The Air Force's own acquisition-center playbook says the hard part plainly: "Requirements definition is the most important and most difficult part of services acquisitions."
Across four published Air Force and DoD documents we read, none names a requirements data standard. The guidance says format examples can be requested and will be part of a guidebook rewrite; the formats themselves are not published. ReqIF 1.2, the nearest thing to an interchange standard, says in its own clause 7.3 that there is no unified language and no shared meta-model, and asks partners to agree on tools before exchange. The 2024 ReqIF benchmark found eight of twelve systems imported cleanly and four partly. GAO has reported thousands of data deliverables per weapon program, 1,274 under one integration contract, and four Army personnel funded to review technical data.
None of this is a data-entry problem. It is a provenance problem. In our reading, when the requirement is the document, the record of why an assertion exists is the document too, and the document cannot be queried. We treat provenance as the engineering object: every element carries where it came from, how it was produced, how confident the producer was, and whether it was abstained.
Capability one
Requirements provenance and traceability.
We build a document-to-model engine. It reads seven structured input families through deterministic readers: bill of materials, cable run sheets, vulnerability scans, DOORS ReqIF, security control exports, IP-PPS tables, and typed requirement text. It produces a typed intermediate model with 22 element kinds, 12 relation types and 14 document types. Validation runs five rule families — provenance completeness, provenance consistency, typed-property rules, stereotype consistency, and top-level index equality — with graph-integrity checks beside them. The model emits ReqIF and carries round-trip tests. An append-only acceptance log records each human acceptance or edit as an explicit patch, with the editor, the reason and a timestamp, never as a silent overwrite.
Every element carries five provenance fields: artifact_id, location, method, confidence and abstention. The method field is one of five families, each carrying a version: a rule set, a language model, a vision model, an OCR tool, or a human author. A reader can therefore ask of any assertion which mechanism produced it, and whether the model chose to abstain rather than guess.
What this is not, stated plainly: PDF is out of scope by design and the reader refuses it. The engine handles one document set at a time; portfolio-scale validation is work to be done. There is no policy-authoring surface; the rules are code. A review shell exists over one loaded document; a documented integration API does not. Extraction accuracy on real documents is unmeasured, and this page does not present a precision figure.
The record
What the record looks like.
A submitted requirement set contains this sentence on page 14, section 3.2: "The system shall record each approval with the approving official and a timestamp." The engine records it with its provenance, not with a blank. A compact version of the record is below; the technical note carries the full worked example.
| Field | Illustrative value |
|---|---|
| Element | REQ-014 — requirement |
| Source (artifact_id) | appendix-c |
| Location | page 14, section 3.2 |
| Method | rules:<parser>:<version> |
| Confidence | 0.86 (illustrative) |
| Abstention | false |
| Check | source exists in the artifact manifest; location inside its page count; abstention consistent with confidence |
A second element, a cross-reference to an appendix that was not submitted, is kept and marked abstention: true. Its provenance is recorded the same way. The difference between a guess and an abstention is visible in the record.
Illustrative, not a customer record. The model is described in the technical note; the schema is not published.
Capability two
Helm: the governed AI workspace.
Helm gives a firm its own instance for work that cannot leave, on the models the firm names, with tool calls and approvals written to a record the firm can check. It runs as one instance per firm on two deployment paths: hosted by HARBOR today, or installed in the firm's network for a pilot. Helm is live at helm.harborgovcon.com; the signed-in workspace is behind authentication.
The record is the point. A buyer does not have to accept that an action happened; the record is written as the work runs, and the firm can inspect it. The record covers tool calls and approvals. It does not cover everything a person reads, and this page does not claim that it does.
Helm is the product; the engine described above is the machinery behind the discipline. In our judgement, one discipline is doing the work on both surfaces: a record a second party can check.
Capability three
HARBOR Port: the federal data layer.
HARBOR Port is Helm's federal data layer and a standalone developer product. It exposes 18 federal source servers and 147 tools behind one endpoint; five of the tools are account and service helpers, and the remaining 142 are federal data tools. The catalogue and the health endpoint are public, so the counts can be checked rather than taken on faith: port.harborgovcon.com/api/catalog and port.harborgovcon.com/healthz.
Port gives a tool call a named federal source. The mechanism is the same as the rest of this page: a named source, a stated call, and a result that can be inspected.
Open HARBOR Port, Helm's federal data layer (opens in new tab)
Registry facts
The entity behind the work.
| Legal name | HARBOR INITIATIVE LLC |
|---|---|
| SAM.gov | Active; registered through 1 October 2027 |
| Unique Entity ID | K4CVRY71WQZ8 |
| CAGE code | 260D0 |
| Primary NAICS | 541512 — Computer Systems Design Services |
| Socio-economic status | Veteran-owned, minority-owned and subcontinent Asian American-owned; self-certified in SAM.gov |
| Location | Missouri City, Texas |
| Contact | ap@harborgovcon.com |
HARBOR INITIATIVE LLC is the offeror. The registry values above are the values federal systems match. This page publishes no street address; the registered address is on the SAM.gov record.
Next step
The next step.
If you are evaluating whether this machinery fits a requirement, talk to us. The conversation is technical: the requirement, the input formats, the record you would need, and the parts of this that are not built yet.
Technical conversation: ap@harborgovcon.com · harborgovcon.com/contact
HARBOR Initiative LLC · Capability · 4 November 2026
Bring a technical question.
The conversation is technical: the requirement, the input formats, the record you would need, and the parts of this that are not built yet.