Agnostic Engineer Discovery Protocol

Cross-platform system discovery by identifying the documentation model, introspection tools, and structural abstractions of the environment you are standing in.

Overview

This document establishes a methodology for localized system discovery across POSIX-compliant kernels (Linux, Unix, macOS) and object-oriented environments such as PowerShell on Windows.

The point is not to memorize every command. The point is to identify the documentation access model of the system you are standing in, then interrogate it correctly.

Core Discovery Methodology

In any engineering environment, documentation is accessed through three primary vectors:

  • Reference

  • Instruction

  • Metadata and introspection

Vector 1: The Reference Model (POSIX / Unix-like)

On POSIX systems, documentation is segmented into discrete sections. Accessing them requires the man utility, which parses nroff-formatted source files.

# Syntax: man [section] [subject]
man 7 ip       # Architecture / protocol overview
man 2 socket   # Kernel-level API (syscalls)
man 5 group    # Configuration file structure

Vector 2: The Object-Oriented Model (PowerShell / MAML)

PowerShell treats documentation as a property of the command object itself. Use Get-Help directly to bypass shell aliases and access the full MAML-backed help system.

# Access the full XML-backed documentation
Get-Help Get-NetTCPSetting -Full

# Access conceptual about_ topics (architectural logic)
Get-Help about_Network_Adapters

Vector 3: Metadata and Introspection

Static documentation is only one layer. Real systems also expose metadata through object inspection, symbol tables, and command discovery.

Need POSIX / Unix-like PowerShell / Windows

Command discovery

apropos, whatis, shell completion

Get-Command, Get-Help term

Path to source/help

man -w, package ownership queries

(Get-Help <cmdlet>).HelpUri

Object or symbol introspection

nm -D, strings, file, ldd

Get-Member, object property inspection

Cross-Environment Mapping

Engineering Need POSIX Utility OO Utility

Command usage

man [cmd]

Get-Help [cmdlet]

Keyword search

apropos [term]

Get-Help [term]

Path to source

man -w [cmd]

(Get-Help [cmdlet]).HelpUri

Internal logic

info [package]

Get-Help about_[topic]

API and introspection

nm -D [binary]

`[object]

Execution Strategy

Reading every manual is not the goal. Infrastructure mapping is the goal.

Focus on the structural bridges between systems:

  • The filesystem

  • The network stack

  • Process and resource isolation

Filesystem

Compare how the system exposes structure and device boundaries.

  • Read man hier(7) on Unix-like systems.

  • Read Get-Help about_Providers on PowerShell.

This gives you the difference between Linux path/device conventions and Windows provider abstractions.

Network Stack

Compare the transport model instead of getting distracted by command syntax.

  • Read man tcp(7) on Linux.

  • Explore the NetTCPIP module help on Windows.

The CLI differs. The underlying RFC-driven behavior often does not.

Process Isolation

Compare how each operating environment reasons about containment and segmentation.

  • Read man namespaces(7) on Linux.

  • Read Get-Help about_Job_Details on Windows.

Different toolchains, same underlying engineering question: how are resources isolated and controlled?

Working Heuristic

When entering an unfamiliar system, ask in this order:

  1. Where does this environment keep authoritative reference material?

  2. How does it expose conceptual documentation?

  3. What are the native introspection tools?

  4. What are the core abstractions: files, objects, sockets, services, jobs, namespaces, providers?

  5. Which layer is the shell showing me, and which layer is it hiding?

This keeps discovery disciplined instead of random.

WSL Note

In WSL, Get-Help inside PowerShell queries the Windows host, while man inside the Linux environment queries the Linux subsystem userland and kernel interfaces.

Always verify which side of the bridge you are interrogating.