vssa-clients/references/system-infrastructure-lifecycle-analysis.md

System infrastructure and lifecycle analysis

Use this method when a cross-client registry needs per-system answers for hosting location, system kickoff, and latest production release.

Scope boundary

Keep these facts in canonical system-level metadata, separate from client-observation rows:

• Client rows prove that one organization owns, operates, uses, procures, or depends on a system.
• System metadata describes the unique system as a whole.
• A client's adoption date, tenant hosting arrangement, or modernization project must not become a shared-system fact unless the source explicitly applies it to the system globally.

Generated system dossiers remain derived views and must never become editable evidence stores.

Required fields

Every unique system record should contain all three fields, even when unknown:

1. hosting_environment
   • known models: cloud, on-premises, hybrid
   • record the named provider or environment when the source states it
2. kickoff_date
   • original system delivery or implementation start
   • precision: year, month, or day
3. latest_release_date
   • latest directly evidenced production release or deployment
   • precision: year, month, or day

Allowed status values are known, unknown, and not-applicable. Unknown and not-applicable values require a concise reason. Known values require direct evidence.

Evidence object

For each known value, preserve at least:

{
  "url": "https://official.example/source",
  "title": "Official source title",
  "quote": "Exact text supporting the asserted value"
}

The quote is a claim guard: it makes reviewers check whether the source really says production hosting, kickoff, or release, rather than merely mentioning a nearby date or technology.

Meaning of the fields

Hosting environment

Accept only explicit production placement evidence. A source may identify a commercial cloud, government cloud, private cloud, institutional data centre, supplier data centre, on-premises deployment, or hybrid arrangement.

Do not infer hosting from:

• DNS, IP ownership, TLS, CDN, or public website hosting;
• eligibility for centralized IT/cloud services;
• a supplier's generic AWS/Azure/GCP capability;
• a SaaS product name without an institution/system-specific hosting statement;
• development, test, backup, or disaster-recovery infrastructure when production is not identified.

System kickoff

Use the original system-delivery or implementation start only when the source describes it as commencement, start, kickoff, or equivalent. Do not silently substitute:

• tender publication;
• contract signature;
• funding approval;
• public launch;
• modernization start;
• project completion.

If only a later modernization kickoff is known, keep the original system kickoff unknown and preserve the modernization date in its proper project/observation context.

Latest production release

Use an explicit production release, deployment, go-live, or version release date. A dated official announcement whose title/body explicitly says the system started operating, launched, went live, or was deployed to production may use the announcement's stated publication date as the release date: the operational statement establishes the event and the official date anchors it. Prefer the earliest authoritative announcement when corroborating reposts differ by a day, preserve all corroborating sources, and do not treat a later repost as a later release.

Do not substitute:

• a webpage updated or publication date when the body does not explicitly establish production operation;
• contract end or project completion;
• acceptance date unless the source also proves production deployment;
• latest tender or maintenance contract date.

Identity-safe canonical storage

Prefer a canonical metadata file keyed by the registry's stable system ID and include the underlying identity key as a guard:

{
  "schema_version": 1,
  "systems": {
    "SYS-XXXXXXXXXX": {
      "identity_key": "name:canonical identity",
      "hosting_environment": {"status": "unknown", "reason": "...", "evidence": []},
      "kickoff_date": {"status": "unknown", "reason": "...", "evidence": []},
      "latest_release_date": {"status": "unknown", "reason": "...", "evidence": []}
    }
  }
}

Require exact coverage of all generated system IDs. Missing records must fail validation rather than silently defaulting to unknown, because omission and researched-but-unknown are different states.

When aliases, normalization, or client-scoped labels change, generated IDs may change. A bootstrap helper may add missing unknown skeletons, but it must:

• never overwrite researched values;
• stop on stale IDs;
• require manual evidence migration for merges and splits;
• preserve the identity_key check.

Validation rules

Fail generation/build when:

• metadata IDs differ from generated registry IDs;
• an identity key does not match;
• any required field is absent;
• a status or hosting model is outside its controlled vocabulary;
• a known value lacks a direct HTTP(S) source, title, or quote;
• an unknown/not-applicable value lacks a reason;
• a date does not match its declared precision;
• generated JSON omits the analysis fields or retains an old schema version.

Publish canonical metadata as a byte-identical raw artifact with a checksum. Include the analysis in machine-readable registry JSON and generated system pages.

Research rotation

A recurring research job should, for every unique system touched in a client batch:

1. Search explicitly for production hosting, original kickoff, and latest production release.
2. Open and classify every candidate source.
3. Update only directly supported fields.
4. Preserve explicit unknowns for the rest.
5. Regenerate, validate, build, inspect the complete diff, and verify published page and JSON output.

Initial migration should create explicit unknown records for full coverage. It must not mine existing prose automatically and turn nearby cloud or date mentions into system-level facts.