Feat/agile operations

[mohammad-ashraf-187]

In this Branch i have worked on Supply Chain,Network Infrastructure and entity resolution kyc

[jim-limprasert-tigergraph]

I think it may be more readable if we split up this big queries.gsql file into smaller query files so that it's more manageable to take a look at those.

[jim-limprasert-tigergraph]

I like this detailed query description format - reminds me of some coding style guide!

It would be a bit tedious if we were to apply this towards ALL the solution kits though, so maybe we might need Robert's or other Solution Engineer's opinion around that.

For query outputs... I think it's fine to mention it out like this (could be helpful for those who run the query and see the different JSON keys). Some queries may have a lot of objects in the output, which made it harder to list out all the outputs explicitly. So, I would say that for those queries, it could be fine to not list all those outputs (or only mention the outputs abstractly without explicitly saying which variables are returned).

[jim-limprasert-tigergraph]

comment: I generally would try using standard non-extended ASCII characters (e.g. stuff you can write out using keyboards) for things in query comments.

So, I'd change the above to be like this so that standard characters are used

Suggested change

	Router → Firewall → Switch → Server
	Also explores multiple downstream Switch layers (k-hop depth traversal).
	Key Features:
	✔ Identifies all downstream devices classified by device type.
	✔ Follows device hierarchy dynamically based on input device type.
	✔ Limits multi-hop Switch traversal using k_hop_switch_limit.
	✔ Returns devices and connecting edges for visualization.
	Router -> Firewall -> Switch -> Server
	Also explores multiple downstream Switch layers (k-hop depth traversal).
	Key Features:
	- Identifies all downstream devices classified by device type.
	- Follows device hierarchy dynamically based on input device type.
	- Limits multi-hop Switch traversal using k_hop_switch_limit.
	- Returns devices and connecting edges for visualization.

This is pretty small stuff though and probably depends on personal preference.

[jim-limprasert-tigergraph]

Question - why do we change the type here from DATETIME to STRING - are there issues when the id type here is a DATETIME?

[mohammad-ashraf-187]

Yes, there is issue if we try to load the datetime datatype it loads default datetime value,

[jim-limprasert-tigergraph]

Thanks for including the purpose for some of these queries that detail out how the query works!

I don't think you need to put in detail how the query works for all the queries (for, say, future solution kits) as it will take some more time to do that. If there's a pretty complicated queries and you want to put in those details - I'll try restricting it to just a few lines/bullet points.

[jim-limprasert-tigergraph]

You can see the comments around using the "keyboard characters" around those - hence the suggestion below

Suggested change

	• event_id — Event identifier
	• event_time — Timestamp of the event
	• event_type — Type classification (Security, System, Network, etc.)
	• event_alert_type — Enriched alert type data (if any)
	• event_incident_type — Enriched incident type data (if any)
	• impacted_devices_list — Devices affected by this event
	> event_id — Event identifier
	> event_time — Timestamp of the event
	> event_type — Type classification (Security, System, Network, etc.)
	> event_alert_type — Enriched alert type data (if any)
	> event_incident_type — Enriched incident type data (if any)
	> impacted_devices_list — Devices affected by this event

[jim-limprasert-tigergraph]

Not all the events are linked to Alerts and Incidents (e.g. Event with type Server Back Online wouldn't be an Incident or Alert).

So, for the current solution kit schema:

• not all events are incidents or alerts.
• All alerts are events.
• All incidents are events.

I guessed you can mention it like this:

Suggested change

	• Searching for events (Alerts, Incidents) that occurred within a time window
	starting from the incident occurrence time
	• Searching for events (which also includes alerts and incidents) that occurred within a time window
	starting from the incident occurrence time

[jim-limprasert-tigergraph]

Suggest: To make it more consistent with the other works in the other queries here, I would recommend:

• Changing the order here (e.g. Parameter should appear before the Output description)
• Maybe change the names too (e.g. Inputs instead of Parameter)

This also applies to other query descriptions with the parameter happening

Suggested change

	Key Outputs:
	- routers_to_display → Starting routers
	- switches_to_display → Switches on the unsecured path
	- servers_to_display → Potentially unsecured servers
	- edges_to_display → All traversal edges for graph visualization
	Parameter:
	k_hop_switch_limit → Maximum number of Switch-to-Switch traversal hops (default: 3)
	Inputs:
	- k_hop_switch_limit → Maximum number of Switch-to-Switch traversal hops (default: 3)
	Outputs:
	- routers_to_display: Starting routers
	- switches_to_display: Switches on the unsecured path
	- servers_to_display: Potentially unsecured servers
	- edges_to_display: All traversal edges for graph visualization