IS373 Review 1 Plan Portfolio and RAG App

Derrick Parker · IS373 Review 1 Plan · Prepared November 9, 2026 Due: November 17, 2026 at 1:00 p.m. Eastern · Individual submission

Direction: cloud/platform IT. Product: a professional portfolio and Newark Civic Pulse, a small Newark public-records RAG app. The November 10 Newark direction supersedes the original Docker-documentation corpus. Reuse the existing FastAPI application and GitHub project; keep the earlier Docker work as provenance.

This is the combined individual record. It covers the portfolio and individual RAG app. The separate team content-system plan belongs in the group review. The partner can review this individual work; no partner implementation or feedback is claimed here.

Status, November 10, 2026: Newark Civic Pulse is publicly deployed with seven official Newark sources, eight chunks and eight compatible real embeddings. Chatbot and research/methods return HTTP 200. Current runtime package 72c8c52954d4 adds pinned timezone data; application logic and the civic fingerprint remain unchanged from the initial 65c0e49 hosted trial/recovery checks. Draft PR #7 remains open/unmerged; Linux and Windows CI both passed at the exact current package head. Local checks passed 217 tests. Portfolio work, learner verification, human peer review and Canvas submission retain their separate pending statuses.

Research index

• Section 1: original employers J1 OpenAI, J2 Canonical support and J3 Canonical graduate cloud → two-direction comparison → target reader and responsibility/evidence map → page outline and Layout A/B decision. Existing evidence: application and hosting.

• Section 2: five primary papers and the instructor reference → retrieval alternatives → Python/SQLite architecture → seven official Newark sources → executed trace → frozen five-question results and hosted C1–C5 checks. Open the Newark-data chatbot, research and methods, recorded evaluation, raw results and published code. Draft review PR #7 is open/unmerged; Linux and Windows CI passed at 72c8c52954d4. Public research and result/receipt access were checked. Historical Docker attachments remain provenance.

• Closing sections: dated actions, requirement audit, partner walkthrough and submission instructions.

• Canvas assignment · Current stage requirements · Research review index

Requirements checked November 10, 2026: Derrick supplied the current Canvas assignment text, including the research workshop clarification. It specifies November 17, 2026 at 1 p.m. Eastern, 100 points, a text-entry submission and both individual headings below. This audit uses that supplied text; it does not establish live Canvas submission status. Actual peer feedback, Derrick’s own claim verification/reflection and instructor access to the final links remain to be completed.

Evidence labels: official source facts are attributed and versioned; actual ETL/model/retrieval/hosted outputs are observations; support reviews are AI judgments, not human peer approval. Fixtures check the behaviors they exercise, not semantic model quality. Specific public/recovery checks are observed; learner/peer review and deferred work remain pending. Local checks and Linux/Windows CI passed at the recorded package revision; their results remain distinct from model-quality observations. No grade, broad production-readiness guarantee or measured gain beyond the small comparison is inferred.

1. Individual portfolio + career research

Target reader and provisional direction

The portfolio will serve an internship or junior-role reviewer looking for practical Linux, cloud support and platform skills. After a short visit, the reviewer should understand Derrick’s direction, inspect evidence of deployment and access-control work, and open the individual RAG project.

Derrick selected cloud/platform IT and an IT-documentation RAG topic. The fit assessment below is an inference from the available coursework and repository evidence, rather than a claim of professional cloud-engineering experience. Graduation date, relocation/travel preferences and full job eligibility have not been confirmed.

Three original employer records

All three employer pages were opened on November 9, 2026. Each displayed an application entry point. That establishes a visible posting/application route, not a guarantee of eligibility or an offer. Posted dates and closing deadlines were not stated in the retrieved descriptions.

J1 OpenAI — Forward Deployed Engineer (FDE) - NYC

Family/industry: customer-facing AI deployment / AI software. Location: New York City; hybrid, three office days weekly; up to 50% travel. Level: experienced reference, not a near-term eligibility claim. Advertised base compensation: $185,000–$300,000 annually plus equity.

Three responsibilities: carry a deployment from discovery to rollout; build full-stack customer solutions; turn field results into reusable tools and evaluation feedback. Supporting excerpt, “In this role you will”: “Own technical delivery across multiple deployments”.

Qualifications: the “You might thrive” profile seeks 5+ years of relevant customer-facing engineering/deployment work, strong Python/JavaScript or comparable coding, and experience with LLM systems. It does not publish separate mandatory and preferred lists; these expectations should not be reclassified as optional.

Existing evidence: the calculator deployment record and its repository show a bounded delivery project. Gap: multi-year customer delivery and evaluated LLM deployment are not established. Next action: by November 12, map one customer-style question to a source-supported RAG acceptance check.

Original posting

J2 Canonical — Cloud Support Engineer

Family/industry: cloud operations/support / open-source software. Location: home based worldwide; regular weekend rotation and in-person company gatherings. Level: full role, not labeled an internship. Salary amount and sponsorship details were not stated.

Three responsibilities: resolve Ubuntu/cloud customer problems; own support cases with clear communication; maintain technical knowledge articles. Supporting excerpt, “The role entails”: “Author and maintain accessible knowledge base articles”.

Qualifications: the stated profile includes a technical degree or explained alternative, practical Linux support, programming fundamentals, and exposure across at least three listed cloud/container/storage/networking areas. Communication, academic record and troubleshooting also matter. No separate preferred-qualification list was found.

Existing evidence: Docker/Traefik deployment documentation and its troubleshooting record provide learning-project examples. Gap: production support across the requested technology breadth is not demonstrated. Next action: by November 12, prepare a reproducible port-routing troubleshooting note and explain what its checks establish.

Original posting

J3 Canonical — Software Engineer - Python - Cloud - graduate level

Family/industry: cloud/platform software engineering / open-source software. Location: home based Americas; global travel is part of the role. Level: explicitly graduate level, providing the junior-career reference. It is not an internship. Salary amount was not stated.

Three responsibilities: develop and test Ubuntu cloud improvements; debug defects and deliver fixes; review code with a distributed team. Supporting excerpt, “The role entails”: “Write high quality code, with unit and functional tests”.

Qualifications: the stated profile includes a bachelor’s/equivalent in CS, STEM or a similar area, extensive Python on Linux, and experience in two or more listed administration, CI, packaging or cloud areas. Open-source community involvement is a bonus. Graduation timing and eligibility remain unconfirmed.

Existing evidence: the FastAPI application’s own feature PRs and contract-check source show relevant coursework. Gap: extensive Python/Linux work and Ubuntu image/packaging experience are not established. Next action: by November 16, define and inspect an import-repeatability check in the RAG plan.

Original posting

These three postings are a small research sample. They do not establish hiring trends or present qualification for the roles. Keep private career reflection directly in the Canvas text entry after Derrick has reviewed it. This shareable record contains suitable goals, source comparisons and project evidence; the private reflection draft is excluded.

Compare two career directions

Provisional choice: cloud/platform IT, with FDE as a comparison. It builds on the evidence already available while the RAG project adds retrieval, evaluation and service-integration experience. The next experiment is whether the finished case studies let a reviewer identify that direction and inspect a concrete result.

Public introduction draft: “I’m Derrick Parker, an IT student at NJIT focused on cloud systems, Linux and networking. My coursework includes Docker/Traefik deployment and a FastAPI app with accounts and server-enforced roles. I’m planning a small documentation assistant to practice retrieval, evaluation and reliable service operation.”

Responsibility to evidence map

Inspected source revisions: application b7e958d6ce7935f7cad5b3f55599d4d16f1ea5e9; hosting 917ffe71b54183d57410437de1fbee1629cdf261. The application checkout was clean. These are source/revision observations, not new execution or hosted-availability checks.

• Application repository · role PR 6

• Hosting repository · deployment PR 2

• Deployment specification · application specification

The existing calculator URL is recorded in the deployment specification. Its live availability was not rechecked for this Plan. Instructor-operated synthetic trial receipts in the repository’s review folder are excluded as evidence of Derrick’s own learning.

Portfolio content and layout decision

GitHub is verified as Y-Just-Y. Résumé, LinkedIn and the preferred public contact route must be confirmed before publication; no invented profiles or addresses will be used. The current Newark Civic Pulse app remains existing project evidence, rather than being presented as an already finished personal portfolio.

Layout A — evidence first: introduction → three project cards → deployment/retrieval check evidence → about/contact. Layout B — biography first: long introduction and background → skill list → project case studies → contact. Both use exactly the same material.

Selected proposal: Layout A. A cloud/platform reviewer can reach the deployment, setup and check links earlier. This is a design hypothesis, not an observed preference from a real recruiter. Keep a restrained charcoal/ivory palette from the existing app, one accent, readable type and explicit “planned” status badges. The professional character is factual and transparent. Demonstrate ability through inspectable work; omit invented endorsements or credentials.

Planned portfolio checks: keyboard navigation, clear focus, mobile reading order, working links, public project access without signup, and a real peer finding the direction and one evidence link.

Changed: selected a direction, mapped employer responsibilities to portfolio content and rechecked the plan against the November 10 Canvas text. Checked: original employer pages, local source revisions and existing project links were inspected. New site behavior and user preference have not been tested. Next: Derrick verifies the cited claims and reviews the private reflection for Canvas; confirm contact assets; obtain the partner’s actual judgment on whether the target reader and featured evidence follow J1–J3, then record the decision and any documentation change before November 17.

2. Individual RAG app + technical research

Dated actions and requirement audit

All dates are 2026. The instructor’s current milestones also mention an individual PowerPoint for Demo Day; that is a later final requirement, not additional work for this Plan.

Rubric alignment: the Canvas rubric assigns 25 points each to Complete, Thoughtful, Checked and Understood. Mapped content supports completeness; alternatives and bounded decisions support thoughtfulness; source inspection, actual model/evaluation outputs, local automated checks and specific hosted/recovery observations provide checking evidence with limits. Derrick still needs to verify AI-generated claims against originals and explain choices in his own words. Human peer feedback, portfolio/private reflection, final access review and Canvas submission remain pending. This audit is not a grade or a claim that every later-stage requirement is complete.

The original partner-walkthrough wording below is retained as prepared for the earlier Docker plan. For the current Newark trace, use executed Q3 and the five actual results; real peer feedback still must be collected.

Partner walkthrough

Ask the partner to navigate without an explanation first:

1. Ask whether the target cloud/platform reader and featured evidence follow from J1–J3; trace one original employer responsibility to a portfolio decision and an existing work link.

1. Follow permitted S01/S05 through the proposed chunks, retrieval and Q1 answer. Explain how missing S01/S05 or a false EXPOSE claim would fail Q1, and distinguish expected behavior from an executed result.

1. Challenge the SQLite/Rust/NATS choice and propose one small check that could change it.

1. Add the real reviewer/date, useful feedback or question, Derrick’s decision, any changed documentation link, and verification/open limits to this existing record. A reasoned decision to keep the plan can be recorded; no new issue quota or separate report is required.

Current peer status: no name, review date, feedback, approval or retest has been supplied. Do not fill these fields from AI roleplay. The later Improve stage still requires real peer feedback, a meaningful change and retesting.

Authorship and help

Derrick chose the project direction and requested the change from Docker documentation to his Newark website, real data, ETL, an AI bot and agent assistance; he selected OpenAI and configured the key privately. AI agents researched sources, wrote integration code/tests/evaluation and drafted the updated technical record. The summaries and evidence-support reviews are AI-authored, not Derrick’s personal reflection or a human partner’s words. Earlier technology preferences are retained as history; deferred tools and unverified claims stay labeled. No learner motivation, peer comment, grade or unmeasured result is invented.

Canvas hand-in

Submit in the individual Review 1 text-entry box using the exact headings “1. Individual portfolio + career research” and “2. Individual RAG app + technical research.” Under each, link the corresponding part of this single evolving record and the relevant repositories, sources and actual check evidence, and retain a short changed/checked/next note. Keep the reviewed private career reflection directly in Canvas under the portfolio heading; do not add it to this shareable record. Confirm that the instructor can open the record and attached checks; a private link alone does not grant access.

The record has not been submitted to Canvas. The supplied assignment text confirms November 17, 2026 at 1 p.m. Eastern and makes a hosted application optional at Plan; working hosted foundations are required at Build. Before hand-in, complete the real peer response and Derrick’s review, verify link access, and retain the Canvas submission receipt.

Course and technical references

Course briefs and handouts read November 9, 2026:

• Portfolio brief

• Individual RAG brief

• Milestones and rubric

• Career research handout

• Vector/graph/RAG handout

• Research review index

Primary technical references read for the original Plan and November 10 Newark update; the five research papers and instructor reference above support specific choices, not unmeasured project gains:

• Lewis et al., RAG, Karpukhin et al., DPR, Wang et al., RAG best-practice comparison, Es et al., RAGAS and Liu et al., Lost in the Middle — primary passages mapped to choices and limits in Section 2.

• Qdrant vector-search documentation — vector approach comparison.

• Neo4j graph-database introduction — graph approach comparison.

• SQLite FTS5 and WAL — keyword ranking and concurrency constraints.

• sqlite-vec and KNN queries — separate vector extension and query choices.

• MiniLM model card — historical proposed embedding option; superseded here by actual OpenAI text-embedding-3-small vectors.

• NATS JetStream and Rust async-nats — researched durable-job option, deferred in the current direct Python implementation.

• Gemini pricing and billing guidance — historical provider research; OpenAI is now configured privately and was used for the recorded run. Provider setup and API access must not be inferred from this old Gemini comparison.

The supplied classroom photos informed the questions about SQLite concurrency, extraction and durable messaging. They are classroom context rather than proof that a specific stack or benchmark is mandatory.

"""Small Plan-only chunk-boundary exercise on an authored paraphrase.

This is not a document import, embedding benchmark, or generated RAG answer.
"""
import hashlib
import json
from pathlib import Path

ROOT = Path(__file__).resolve().parent
PARAGRAPHS = [
    "Publishing ports\nDocker can forward a host port to a container port. In a mapping such as 8080:80, the host port is written first and the container port second.",
    "Network exposure\nPublishing a port normally listens on every host interface. Binding the mapping to 127.0.0.1 limits host access to the loopback address.",
]
fixture = "\n\n".join(PARAGRAPHS)
size = 120
fixed = [fixture[i:i+size] for i in range(0, len(fixture), size)]
answer = "the host port is written first and the container port second"
results = {
    "kind": "observed locally on an authored paraphrased fixture",
    "source": "S01 / Publishing and exposing ports",
    "fixture_sha256": hashlib.sha256(fixture.encode()).hexdigest(),
    "units": "Python Unicode characters, not model tokens",
    "fixture_characters": len(fixture),
    "paragraph_chunk_count": len(PARAGRAPHS),
    "fixed_chunk_characters": size,
    "fixed_chunk_count": len(fixed),
    "paragraph_answer_in_one_chunk": any(answer in p for p in PARAGRAPHS),
    "fixed_answer_in_one_chunk": any(answer in p for p in fixed),
    "paragraph_chunks": PARAGRAPHS,
    "fixed_chunks": fixed,
    "limitation": "Boundary inspection only; no tokenizer, embeddings, live source import, retrieval evaluation or generation ran.",
}
(ROOT / "chunk-exercise.json").write_text(json.dumps(results, indent=2)+"\n")
print(json.dumps(results, indent=2))

{
  "kind": "observed locally on an authored paraphrased fixture",
  "source": "S01 / Publishing and exposing ports",
  "fixture_sha256": "66eb97076878f012425547505560dc1cbd9b4cf01ba1b790603c0f21dd64e528",
  "units": "Python Unicode characters, not model tokens",
  "fixture_characters": 315,
  "paragraph_chunk_count": 2,
  "fixed_chunk_characters": 120,
  "fixed_chunk_count": 3,
  "paragraph_answer_in_one_chunk": true,
  "fixed_answer_in_one_chunk": false,
  "paragraph_chunks": [
    "Publishing ports\nDocker can forward a host port to a container port. In a mapping such as 8080:80, the host port is written first and the container port second.",
    "Network exposure\nPublishing a port normally listens on every host interface. Binding the mapping to 127.0.0.1 limits host access to the loopback address."
  ],
  "fixed_chunks": [
    "Publishing ports\nDocker can forward a host port to a container port. In a mapping such as 8080:80, the host port is writ",
    "ten first and the container port second.\n\nNetwork exposure\nPublishing a port normally listens on every host interface. B",
    "inding the mapping to 127.0.0.1 limits host access to the loopback address."
  ],
  "limitation": "Boundary inspection only; no tokenizer, embeddings, live source import, retrieval evaluation or generation ran."
}