starlinetor/cybersecurity_class_2026

1. This repository is really two separate workspaces:

- a LaTeX-based research/reporting workspace under ResearchReport and Research_essay_template_EasyChair

- a Python authorization project under topic-a-authorization/topic-a-authorization

2. The LaTeX side is a document-production pipeline, not an application runtime.

The important source files are ResearchReport/main.tex and Research_essay_template_EasyChair/EasyChair3.5/easychair.tex, with bibliographies in .bib files and the compiled PDFs/logs as build outputs. These folders are oriented around writing, compiling, and packaging a research paper on “Network Encryption and Traffic Analysis.”

3. The LaTeX subsystem has a clear source-to-artifact flow:

manuscript .tex + bibliography .bib + template class/files → compiled .pdf and intermediate build products (.aux, .bbl, .log, .synctex.gz, etc.).

Those generated files are present in the repo, so an architecture diagram should show them as outputs of a documentation build step, not as inputs to the software system.

4. The topic-a-authorization project is the actual executable software in the repo.

It is a standalone Python 3 authorization engine that consumes JSON datasets describing subjects, resources, policies, and requests, then produces an authorization decision output in JSON.

5. The runtime entrypoint is topic-a-authorization/main.py.

This is the top-level orchestrator: it likely wires together input loading, policy evaluation, and output writing. The architecture should treat it as the single command-line entrypoint rather than a service with multiple deployable components.

6. Input data is partitioned into four domain files in input/:

- subjects.json

- resources.json

- policies.json

- requests.json

This separation suggests a rule-evaluation model where identities, protected assets, and access requests are loaded independently and then matched by the engine.

7. The core logic is in src/engine.py.

That module is the authorization decision boundary: it should be depicted as the subsystem that evaluates requests against policies using the loaded subject/resource data. The repo structure implies that this is the only part containing domain logic, while the other modules are support utilities.

8. src/loader.py is the input boundary.

Its role is to read and normalize the JSON files from the input/ directory so the engine can work with in-memory Python objects. In the diagram, this sits between filesystem data and the decision engine.

9. src/verify_json.py is a validation/checking utility.

It likely ensures the generated or test JSON conforms to expected structure before use or before comparison. This makes it part of the quality/control boundary rather than the authorization logic itself.

10. output/output.json is the produced artifact of the authorization run.

The repo also contains test_input/ and test_output/, which indicate a file-based test harness: known inputs are run through the engine and compared with an expected JSON result. That makes the system easy to diagram as a deterministic batch processor.

11. src/tests.py is the test layer for the Python project.

It appears to exercise the engine against the bundled test fixtures, so tests are local and offline; there is no evidence of external APIs, databases, or network dependencies in the architecture.

12. At a high level, the important architectural boundary is file-based data processing:

JSON inputs → loader/validation → authorization engine → JSON output, with tests using parallel fixture directories to verify behavior.

The LaTeX materials are independent of that runtime and should be shown as a separate documentation/reporting subsystem.