fall2026-application-preparation

SPAR Fall 2026 — Application Preparation Plan

Scope: prepare primarily for Tier 1 and Tier 2 projects in fall2026-projects.md. Tier 3 is treated as a source of backup options and transferable preparation. Tier 4 receives only incidental attention. Tier 5 is omitted completely.

Tailored profile: legal background; former judicial associate in a Polish court; current backend engineer using Java/Kotlin and Python; completed ML upskilling through ARENA and Neel Nanda’s mechanistic-interpretability materials; strongest jurisdictions are Poland and the EU; approximately 18 days available.

1. Target portfolio

Fit-adjusted Tier 1 — primary targets

1. Project 15 — Mechanistic Interpretability, Artificial Intent, and AI Legal Responsibility
   • Exceptional intersection of law, software engineering, ML study, and mechanistic-interpretability familiarity.
2. Project 14 — Poland-specific Public-Sector AI Resilience Agenda (bumped from Tier 2)
   • Exceptional intersection of Polish public-sector experience, court operations, law, and backend systems.
3. Project 20 — A Design Blueprint for Middle-Power AI Safety Institutes
   • Strong fit for Polish/EU institutional and legal analysis, with enough technical background to understand evaluation functions.
4. Project 13 — Writing a Textbook for AI Governance (bumped from Tier 2)
   • Strong fit for translating law and technical governance for non-specialists.

Fit-adjusted Tier 2 — serious secondary targets

1. Project 03 — Interoperability Standards for Agentic AI (bumped from Tier 3)
   • Law plus backend engineering is unusually well suited to reading a protocol specification and identifying its governance implications.
2. Project 06 — Token Taxes
   • Prepare only for RQ2, legal implementation. RQ1, RQ3, and RQ4 demand more specialized evidence than the current profile establishes.
3. Project 07 — Catastrophic Risks of AI in Space
   • Remains a high-interest project, but receives less preparation time because there is no demonstrated space-systems or cybersecurity background.

Recommended application strategy

Use one integrated application strategy rather than preparing seven independent applications:

• Primary specialist lane — law and interpretability: Project 15.
• Poland/EU institutional lane: Projects 14 and 20.
• Expository governance lane: Project 13, supported by the same research used for Projects 14 and 20.
• Technical-standards lane: Project 03, using backend engineering experience to analyze MCP or a related protocol.
• Selective backups: Project 06 RQ2 and Project 07.

The main writing sample should serve Projects 15 and 13. A smaller Poland-focused institutional memo and diagram should serve Projects 14 and 20. Project 03 needs one close protocol reading. Do not spend scarce time building a token-tax model or learning space engineering from scratch.

Personal advantages to make explicit

• Legal reasoning: experience identifying legal issues, interpreting authority, distinguishing holdings from policy arguments, and writing precisely.
• Inside view of public institutions: court experience gives concrete knowledge of case flow, procedural duties, limited administrative capacity, escalation paths, and the consequences of backlogs.
• Production software judgment: backend experience supports reasoning about interfaces, permissions, logging, failure modes, observability, system boundaries, and implementation constraints.
• Technical AI literacy: ARENA and mechanistic-interpretability study provide a credible bridge to technical papers without overstating ML research experience.
• Polish/EU jurisdictional fit: Poland is a concrete middle-power case with active AI Act implementation and a newly designed national supervisory architecture.

Gaps to handle honestly

• No existing writing sample: one must be produced and polished during the 18-day window.
• No demonstrated academic mechanistic-interpretability research: describe structured study and technical comprehension, not research expertise.
• No space-systems or cyber-operations record: Project 07 answers must be carefully sourced and physically grounded.
• Token-tax eligibility is strongest for legal RQ2 only; do not imply economics, formal-verification, or agent-based-modelling credentials that are not established.

2. What the fit-adjusted priority projects collectively test

Capability	Where it matters most	Evidence to prepare
Concise analytical writing	All priority applications	One polished policy/research sample plus timed 200–500 word answers
Primary-source research	13, 14, 15, 20	Notes based on laws, budgets, institutional reports, standards, and technical papers
Institutional and policy reasoning	06, 13, 14, 20	A memo that identifies actors, mandates, incentives, constraints, and implementation steps
Technical comprehension without overclaiming	07, 13, 15, 20	One explainer translating a technical mechanism for a policy or legal audience
Counterargument and uncertainty	All priority applications	Steelman the opposing view; distinguish evidence, inference, and speculation
Independent project design	06, 07, 13, 14, 15	A scoped question, method, milestones, risks, and a plausible output
Structured comparison	06, 14, 20	A small dataset or comparison table with an explicit coding rubric
Technical implementation	Only selected tracks in 06; useful in 07	Small reproducible model, threat model, or audit demonstration

3. Shared preparation core

Complete this section before project-specific deep dives.

A. Build a current AI-governance map

Be able to explain, in plain language:

• Why advanced AI creates governance problems that ordinary technology regulation may not fully address.
• The difference between capability evaluation, safeguard evaluation, standards, auditing, market surveillance, incident response, and enforcement.
• Governance intervention points across the AI supply chain: chips and compute, training, model release, deployment, inference, and downstream use.
• The roles of governments, frontier developers, AI Safety/Security Institutes, regulators, standards bodies, international networks, and independent researchers.
• Why state capacity, verification, jurisdiction, incentives, and international coordination often determine whether a proposal works.

Core reading

Read selectively and take structured notes; do not try to memorize every report.

1. International AI Safety Report 2026
   • First: executive or extended policymaker summary.
   • Then: sections on loss of control, cyber risk, labour-market effects, monitoring and safeguards, and societal resilience.
   • Output: a one-page map of risk → evidence → available intervention → limitation.
2. Stanford AI Index 2026
   • Prioritize research and development, technical performance, responsible AI, and economy.
   • Output: a page of quantitative facts worth citing, each with its source and caveat.
3. Open Problems in Technical AI Governance
   • Output: define five technical-governance problems and connect each to a policy mechanism.
4. EU AI Act — official text
   • Do not read cover to cover initially. Trace one mechanism from legal duty to evidence, supervision, and enforcement.
5. NIST AI Risk Management Framework
   • Output: explain what a voluntary framework can and cannot accomplish.
6. UK AI Security Institute research agenda
   • Output: classify its functions as research, evaluation, infrastructure, advice, coordination, or regulation.

B. Learn a repeatable research method

For every question, use the same sequence:

1. Define the claim and key terms.
2. Identify the decision-maker and decision being supported.
3. Start with primary sources: legislation, official mandates, budgets, standards, institutional reports, technical papers, and original datasets.
4. Record each source in a literature matrix:
   • citation and link;
   • source type and authority;
   • core claim;
   • method or evidence;
   • limitation;
   • relevance to the application answer.
5. Separate:
   • observed fact;
   • reasonable inference;
   • assumption;
   • speculation or scenario.
6. Seek the strongest counterargument.
7. End with a calibrated conclusion and the evidence that would change it.

C. Train short-form analytical writing

Most application answers are between 200 and 500 words. Use this default structure:

1. Answer first: one or two sentences stating the conclusion.
2. Mechanism: explain why the conclusion follows.
3. Evidence or example: use one concrete, well-chosen source or case.
4. Counterargument: state the strongest objection fairly.
5. Resolution: explain the trade-off, uncertainty, or condition under which the conclusion changes.

Editing checklist:

• Is the first paragraph a direct answer rather than scene-setting?
• Does every paragraph advance one claim?
• Are important terms defined?
• Are factual claims cited?
• Is the causal mechanism explicit?
• Is the counterargument genuinely strong?
• Have unsupported adjectives been removed?
• Does the answer stay within the word limit without tiny formatting tricks?
• Could the answer have been written for any project? If yes, make it more specific.

4. Project-specific preparation

Project 20 — Middle-Power AI Safety Institutes (Tier 1)

Tailored angle

Use Poland as the prospective middle power, but do not pretend Poland already has an AI Safety Institute. The strongest analytical contrast is between:

• Poland’s new AI market-supervision architecture, centred on the Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji (KRiBSI); and
• a technically capable institute that performs frontier-model evaluations and gives government risk advice.

This creates a concrete version of the project’s central question: which safety functions can KRiBSI, EU institutions, and international networks provide, and which capabilities would Poland still need domestically?

Read about

• What frontier-model evaluations measure and how results can support government decisions.
• Institutional design: mandate, statutory basis, independence, budget, staffing, access to models and compute, security clearance, publication policy, and accountability.
• The distinction between functions that require domestic sovereign capacity and functions that can be shared internationally.
• The risk of duplicating an existing regulator versus the risk of placing a technical research mission inside an enforcement-oriented body.
• At minimum, compare:
  • UK AI Security Institute;
  • Japan AI Safety Institute;
  • European AI Office;
  • the International Network of AI Safety Institutes mission statement.
• For the Polish case, read:
  • the final parliamentary text of Poland’s Act on AI Systems, dated 3 July 2026, especially KRiBSI’s legal status, powers, coordination duties, and market-surveillance role;
  • the government summary of the Polish supervisory model;
  • Poland’s AI-development policy to 2030.

Write

• A 300-word answer naming one function Poland cannot easily obtain through an international network. Best candidate: secure, government-accountable evaluation and incident advice tailored to models deployed in Polish critical infrastructure or public services, including sensitive domestic threat information.
• A 300-word steelman of using KRiBSI rather than creating a separate institute, followed by the best response. Treat the minister’s position seriously: cost, democratic accountability, reduced fragmentation, existing legal authority, and EU coordination are real advantages.
• A one-page memo: “Does Poland need an AI Safety Institute alongside KRiBSI?” Include the institutional gap, three possible organizational models, a recommendation, initial functions, and what should remain with KRiBSI or EU bodies.

Work on

• Build a mini comparative dataset covering UK AISI, the European AI Office, Japan AISI, and Poland/KRiBSI. Suggested columns:
  • legal home and independence;
  • mandate;
  • evaluation domains;
  • access to models/compute;
  • staffing and budget evidence;
  • authority to compel information or action;
  • relationship to regulators and ministries;
  • international-network role;
  • unique domestic function;
  • source quality and missing data.
• Create a decision tree: build domestically / procure / partner / rely on network.
• Prepare to defend why your chosen institutional design fits a middle power’s actual resource constraints.
• Add one explicit legal-design question: should a Polish evaluation body sit inside KRiBSI, inside NASK or another technical body, within a ministry, or as a separate institute? Compare independence, access, technical culture, emergency responsiveness, and accountability.

Proof of fit to show

A structured comparison based on primary sources, combined with direct knowledge of Polish public institutions, will be more persuasive than broad enthusiasm for AI governance. Use court experience to discuss institutional capacity and procedural reality, while avoiding claims about executive agencies you did not work in.

Project 15 — Interpretability, Artificial Intent, and Legal Responsibility (Tier 1)

Tailored angle

This is the strongest overall fit. Use a narrow US federal-law anchor, because the application permits US or UK jurisprudence and the relevant literature is substantially richer on the US side. Polish and EU experience remains useful comparative context, but geographic proximity is not a reason to prefer UK doctrine. Avoid writing about “US law” as if it were unitary: criminal law varies across federal and state systems, and mens rea is statute-specific.

Proposed research question and writing-sample title:

From Attribution Graphs to Mens Rea: What Could Mechanistic-Interpretability Evidence Establish Under US Federal Law?

Read about

• Use US federal evidentiary and criminal law and stay consistent in the core doctrinal analysis. Use the Model Penal Code only as a conceptual taxonomy, clearly noting that it is not controlling federal law.
• Mens rea and adjacent standards: purpose, knowledge, recklessness, negligence, and how the required mental state depends on the particular offence and statutory element.
• Evidentiary questions: relevance, reliability, expert testimony, reproducibility, error rates, adversarial testing, and the gap between scientific explanation and legally persuasive proof.
• Read Federal Rule of Evidence 702, including the 2023 amendment’s emphasis on reliable application and keeping opinions within what the methodology supports.
• Read Federal Rule of Evidence 704(b), which prevents a criminal-case expert from stating the ultimate opinion that the defendant did or did not possess the legally required mental state.
• Use selected Supreme Court decisions such as Rehaif v. United States and Ruan v. United States to show why mens rea analysis must remain statute-specific and attentive to subjective knowledge or intent.
• Competing liability models for autonomous systems: developer, deployer, operator, product liability, agency analogies, and legal personhood.
• Mechanistic interpretability basics:
  • sparse autoencoders and feature representations;
  • circuit tracing and attribution graphs;
  • chain-of-thought monitoring;
  • why an explanation of internal computation may still fail to establish intention.
• Start with Anthropic’s circuit-tracing overview and tools and the relevant monitoring/interpretability sections of the International AI Safety Report.
• Start from primary federal authority and then use the US-focused AI criminal-liability literature. Distinguish current doctrine from proposals for synthetic mens rea or AI personhood.
• Revisit one Neel Nanda mechanistic-interpretability resource already studied, then read one recent circuit-tracing paper closely. This lets the application show continuity rather than a hurried new interest.

Write

• A 500-word legal critique of one recent article or policy proposal. Include its main argument, doctrinal context, a significant limitation, and a research path that addresses the limitation.
• A 300-word answer to: “Could mechanistic interpretability ever provide legally persuasive evidence of artificial intention or mens rea?”
• A short comparison of three positions:
  1. interpretability reveals genuine artificial mental states;
  2. it supplies only behavioural or causal evidence relevant to human/legal responsibility;
  3. it is too unstable or theory-laden for legal reliance.
• A 1,500–2,000 word standalone writing sample using the proposed title above. Keep it narrow: the paper need not solve AI personhood or liability generally.

Suggested thesis to test rather than assume:

Mechanistic-interpretability outputs could eventually become admissible expert or circumstantial evidence about an AI system’s computational process, but they cannot by themselves establish mens rea. Under current US federal law, their relevance depends first on whose legally cognizable mental state is at issue and under which offence; their admissibility and weight then depend on validated links between internal features and behaviour, reproducibility, error rates, alternative explanations, and compliance with Rules 702 and 704(b).

Work on

• Make an “evidence chain” diagram: model state → interpretability method → scientific inference → expert testimony → legal element → responsibility.
• At every arrow, list failure modes and alternative explanations.
• Read one interpretability paper closely enough to explain its method, validation, and limits without anthropomorphic language.
• Select or revise an academic writing sample that demonstrates doctrinal precision and interdisciplinary reasoning.
• Use judicial-associate experience carefully: emphasize familiarity with how courts evaluate arguments, records, expert material, and procedural constraints. Do not imply that Polish evidentiary practice answers the US federal doctrinal question.

Proof of fit to show

Demonstrate caution. The strongest answer will neither dismiss interpretability nor treat an attribution graph as a direct readout of intention. Your advantage is being able to explain both why software evidence may matter and why a court requires a legally defined inferential bridge.

Project 07 — Catastrophic Risks of AI in Space (original Tier 1; fit-adjusted Tier 2)

Tailored angle

Apply as a software-and-governance generalist, not as a space or cybersecurity specialist. Backend experience is useful for modelling trust boundaries, identity, authorization, logging, update channels, distributed failure, and recovery. Limit preparation to one credible attack scenario and one carefully constrained loss-of-control scenario; do not let this displace the stronger-fit applications.

Read about

• The project proposal linked from the SPAR listing.
• Space-system architecture: space, ground, user, communications, and supply-chain segments.
• Operational constraints: latency, intermittent communication, limited physical access, power and thermal limits, radiation, long service lives, and patching constraints.
• Threat modelling for command and control, model updates, telemetry, ground stations, inter-satellite links, identity/access, and supply-chain compromise.
• Autonomy hazards: goal misspecification, distribution shift, degraded sensors, loss of human override, emergent coordination, and unsafe failover.
• Start with:
  • NIST IR 8441 — Hybrid Satellite Networks Cybersecurity Profile;
  • NIST IR 8270 — Cybersecurity for Commercial Satellite Operations;
  • NASA AI Strategy.

Write

• A maximum-400-word attack narrative with a concrete target, actor, access path, exploit, propagation mechanism, operational consequence, detection opportunity, and layered mitigations.
• A maximum-400-word “rogue AI disconnected from Earth” scenario. Avoid magic. Trace physical capabilities, remaining communication paths, persistence, incentives, dependencies, and credible pathways back to terrestrial harm.
• A one-page risk taxonomy separating:
  • ordinary reliability failure;
  • malicious cyber compromise;
  • loss of control;
  • concentration of power;
  • speculative AGI scenarios.

Work on

• Draw one system architecture and attack surface.
• Build an attack tree for a satellite constellation with onboard AI.
• Create a risk register with likelihood, impact, detectability, reversibility, confidence, and mitigation owner.
• For each mitigation, check whether it still works under communication delay, compromised ground control, and partial constellation compromise.
• Reuse familiar backend concepts where appropriate—service identity, key rotation, least privilege, signed updates, audit logs, failover, quorum rules—but verify their feasibility under spacecraft constraints.

Proof of fit to show

Imagination is useful only when coupled to physical and operational constraints. The application explicitly allows LLM assistance but requires justification, so be ready to explain every step yourself.

Project 13 — AI Governance Textbook (bumped to Tier 1)

Tailored angle

This project rewards the core professional combination: legal source-reading, software architecture literacy, and clear explanation. Use the interpretability-and-mens-rea paper as the principal writing sample, but prepare the application explainer on a more conventional governance mechanism to demonstrate breadth.

Recommended explainer topic:

How the EU AI Act divides oversight of general-purpose AI between the European AI Office and national market-surveillance authorities—and why the division matters.

This topic connects EU law, Poland’s new institutional architecture, and the technical question of which body can evaluate what.

Read about

• The three sources named in the listing: International AI Safety Report 2026, Stanford AI Index 2026, and Open Problems in Technical AI Governance.
• One mechanism deeply rather than ten mechanisms superficially. For this application, prioritize the EU AI Act’s supervision of general-purpose AI and its interaction with national authorities. Other candidates are:
  • a compute threshold;
  • a frontier-model auditing regime;
  • a specific EU AI Act obligation;
  • model evaluation and reporting triggers;
  • verification in an international agreement.
• Read the mechanism’s primary legal or technical source, its best explanation, and a serious critique.

Write

• A 400–500 word textbook-grade explainer for a smart non-specialist:
  • define the mechanism;
  • explain how it works step by step;
  • state why it matters;
  • identify limitations and open questions;
  • cite primary sources;
  • mark one location for a figure or worked example.
• A 300-word note separating:
  • durable layer: concepts, institutions, incentives, verification problems, and analytical frameworks;
  • current-events layer: officeholders, thresholds, implementation dates, current models, and institutional names.
• A short disclosure for the writing sample: audience, what it explains, why the technical/legal bridge matters, and that it was independently produced for application preparation.

Work on

• Reverse-outline a strong survey or textbook chapter: record the purpose of each section and how definitions accumulate.
• Make a concept dependency map showing what a reader must understand first.
• Edit one previous piece for exposition: replace link-dumping with a connected causal explanation.
• Ask one knowledgeable reader to mark every sentence they had to reread.

Proof of fit to show

The key signal is expository judgment: selecting what is load-bearing, sequencing it well, and explaining implications accurately. Legal precision is an advantage only if the result remains readable to a smart non-lawyer.

Project 14 — Poland-Specific Public-Sector AI Resilience (bumped to Tier 1)

Tailored angle

This is an excellent fit because former court work supplies something most applicants will lack: a concrete view of how legal duties, case-management systems, staffing, procedural safeguards, and backlogs interact.

Recommended focus:

Preparing Polish courts and administrative bodies for agentic flooding: how should the public sector respond when AI makes legally valid submissions, appeals, complaints, and information requests dramatically cheaper to generate?

The output should be framed as a policy memo, not a prediction that flooding will definitely occur. Courts can be the best-developed case study, while the whole-of-government implications remain visible.

Read about

• Polish machinery of government and judicial administration: relevant ministries and court-administration actors, procedural rule-makers, IT-system owners, data-protection and cybersecurity bodies, budgeting, procurement, audit, and escalation paths.
• Existing AI-focused bodies and the limits of their mandates.
• Public-sector continuity, emergency preparedness, cyber resilience, and cross-government coordination.
• Agentic flooding in depth: distinguish malicious flooding, commercially automated bulk filing, genuine increased access to justice, low-quality but legally cognizable submissions, and AI-assisted self-representation.
• OECD — Governing with Artificial Intelligence: Are Governments Ready? as an initial orientation, followed by primary sources for the chosen jurisdiction.
• Poland’s AI policy to 2030, the Polish AI implementation act, and official guidance collected at AI.gov.pl.

Write

• A 100-word project focus naming Poland, agentic flooding, a court/public-administration case study, and a policy memo as the output. Mention both judicial-associate and backend-engineering experience.
• A 200–400 word rapid assessment of whether Poland would respond well. Consider legal duties to receive and process submissions, fragmented ownership, limited surge capacity, existing digital channels, cybersecurity capability, and the difference between filtering abuse and denying access to justice.
• A one-page institutional memo answering:
  • who detects the problem;
  • who owns the response;
  • who can compel coordination;
  • what information is needed;
  • what capacity is missing;
  • what should be built before a crisis.

Work on

• Draw the current chain of command for one scenario.
• Run a tabletop exercise: write a short incident inject, then identify decisions at 24 hours, 7 days, and 90 days.
• Identify three realistic changes to mandates, reporting, staffing, procurement, or exercises—rather than proposing a new office by default.
• Build a simple queue model in Python only if it clarifies the memo: arrival rate, processing capacity, triage accuracy, backlog, and time-to-disposition. Keep assumptions visible; this is an explanatory artifact, not a forecast.
• Produce a system-and-responsibility map covering submission channel, identity/authentication, case-management intake, triage, human review, appeal, audit, privacy, and incident escalation.

Proof of fit to show

Specific knowledge of how a court actually operates will outperform generic claims that coordination or preparedness should improve. Show that resilience must preserve legality, due process, and access to justice—not merely maximize throughput or block automated users.

Project 06 — Token Taxes (Tier 2)

First decision: select an eligible research question

Prepare RQ2 only unless further credentials materially change the fit. The legal background is relevant; backend experience helps explain the taxable event and audit architecture, but does not replace the project’s specified compute-governance or formal-verification prerequisites for RQ1.

For reference, the tracks require:

• RQ1 — auditing token taxes: engineering/CS/applied mathematics, compute governance, black-box auditing, formal verification, Python, transformers/tokenizers.
• RQ2 — legal implementation: advanced law/political-science training, legal research, ideally international-organization experience.
• RQ3 — tax comparison: advanced economics training, tax-policy knowledge, very strong writing.
• RQ4 — agent-based model: engineering/CS background, strong Python and preferably another programming language, interest or experience in agent-based modelling.

Before investing heavily, check whether the legal education meets the listing’s Master’s/PhD expectation. If it does not, keep the application concise and prioritize Projects 15, 14, 20, 13, and 03.

Read about

• Token Taxes: Mitigating AGI’s Economic Risks, especially its audit pipeline and comparison with alternatives.
• How inference is metered, billed, logged, and tokenized; where measurement can be manipulated; and how open-weight or vertically integrated systems complicate collection.
• Tax incidence, elasticity, avoidance, administrative cost, innovation effects, and cross-border enforcement.
• VAT, digital services taxes, corporate income taxes, compute taxes, and excise-style token taxes.
• For RQ2, analyze an EU/Poland implementation path, but distinguish EU competences, domestic taxation, VAT harmonization, state-aid constraints, fundamental rights/data protection, international tax treaties, and trade implications.
• Use software knowledge to describe what must be observed or logged for a token tax, then turn those facts into legal issues: taxpayer identification, place of supply/use, evidence, audit powers, privacy, confidentiality, appeals, and cross-border enforcement.

Write or build

• RQ1: select four genuinely relevant papers and explain what each contributes to auditability, not merely that it mentions compute or tokens.
• RQ2: make an issue tree covering tax base, taxable person, nexus, territoriality, valuation, privacy/data access, trade law, discrimination, treaties, administration, enforcement, and appeals.
• RQ3: build a comparison matrix for auditability, multinational enforcement, incidence, distortion, innovation effects, avoidance, revenue stability, and bureaucratic cost; then turn it into a 400-word argument.
• RQ4: build a minimal, transparent model before adding LLM agents. Specify agents, state variables, behavioural rules, tax pass-through, labour/capital effects, government budget, outputs, sensitivity analysis, and validation limits.

Proof of fit to show

The application should make a narrow, technically grounded contribution to RQ2. A broad essay about inequality is insufficient. The differentiator is the ability to connect actual inference architecture and records to administrable legal rules.

Project 03 — Agentic-AI Interoperability Standards (bumped to Tier 2)

Why it is promoted

The project explicitly values people who can read a technical specification, explain what it obliges implementers to do, reason about institutional process, and write for policy readers. Law plus production backend engineering is a direct match.

Recommended protocol and forum question

• Use the Model Context Protocol specification for the protocol analysis. Focus on authorization, tasks, extensions, change control/deprecation, capability negotiation, and the boundary between protocol guarantees and application policy.
• Compare two candidates for the “most influential forum” answer:
  • the Linux Foundation’s Agentic AI Foundation, which houses MCP under vendor-neutral governance and is close to deployed implementations;
  • the IETF, whose open standards process and Internet-layer legitimacy may matter more for durable cross-vendor communications standards. Start with the IETF discussion of needed agentic-AI standards.
• A defensible answer may distinguish near-term de facto influence from long-term standards legitimacy rather than forcing a false single-axis comparison.

Write

• A 200-word forum answer with explicit selection criteria: adoption, implementer participation, openness, governance legitimacy, speed, interoperability scope, and ability to influence deployed systems.
• A 350-word MCP analysis identifying political implications of:
  • who controls specification changes;
  • what identity and authorization assumptions are externalized;
  • whether permissions and delegation can be revoked;
  • what evidence exists after an agent acts;
  • whether interoperability increases user choice or expands systemic attack surfaces;
  • whether the protocol enables a reliable shutdown boundary or merely a request that implementations may ignore.

Work on

• Build a specification matrix: normative requirement → implementer obligation → actor benefited/burdened → security or governance consequence → unresolved question.
• Trace one end-to-end action from a user through an agent to an MCP tool and back. Mark trust boundaries, credentials, consent, logs, failure handling, and revocation points.
• Optionally build a minimal local MCP demonstration in Python or Kotlin only if it makes the analysis more concrete. The written specification analysis has priority.

Proof of fit to show

Use backend experience to explain implementation reality and legal experience to expose allocation of authority and responsibility. Avoid treating an open-source protocol repository as automatically neutral or democratically legitimate.

5. Tier 3 and Tier 4 treatment

Tier 3 — use as backups and skill multipliers

Do not create separate preparation programs yet. Reuse priority-project work:

• Project 01, US surveillance reform: legal/policy research and stakeholder mapping from Projects 14 and 15.
• Project 05, AI strategy and futurism: evidence of independent research and a clear career narrative.
• Project 08, policy simulation: modelling work from Project 06 RQ4.
• Project 11, persuasion/manipulation: evaluation design and careful operationalization.
• Project 16, AI consciousness: philosophical argument and calibrated uncertainty from Project 15.
• Project 17, strategic stability: concise case analysis and counterargument.
• Project 18, middle-power compute: structured comparison and quantitative literacy from Projects 06 and 20.
• Project 19, normalization of deviance: public-record document analysis from Projects 14 and 20.

Tier 4 — minimal attention

Do not schedule dedicated reading or portfolio work. Apply only if existing preparation nearly answers the application already. Reuse writing samples, research notes, or technical work where appropriate.

Tier 5 is intentionally excluded.

6. Application assets to prepare once

A. A strong writing sample

Produce one primary sample:

From Attribution Graphs to Mens Rea: What Could Mechanistic-Interpretability Evidence Establish Under US Federal Law?

Target length: 1,500–2,000 words, excluding references. Intended audience: legally or technically literate readers who are not experts in both fields.

Suggested structure:

1. Research question and qualified thesis.
2. The selected federal offence or doctrinal context, its mens rea requirement, and how the factfinder infers it.
3. What one selected interpretability method actually produces.
4. Whose mental state is legally relevant: the AI system, a human actor, or an organization.
5. The proposed inferential chain from model internals to a legally relevant proposition.
6. Rules 702 and 704(b), reproducibility, error rates, and alternative-explanation problems.
7. What the evidence could establish, what it could not, and a focused research agenda.

The piece should show:

• a clear research question;
• a defensible thesis;
• use of primary or high-quality sources;
• explicit reasoning rather than summary;
• counterarguments and limitations;
• clean structure and precise prose;
• clear disclosure of your contribution if co-authored or heavily edited.

Use primary legal authority and a primary technical paper. Have one legally trained reader and one technically trained reader review it. Disclose that it is a new, independently written application-preparation sample.

B. A small research portfolio

Aim to finish four compact artifacts, in this order:

1. Primary writing sample plus evidence-chain figure — optimized for Project 15 and reusable for Project 13.
2. Poland institutional memo and comparison table — “Does Poland need an AI Safety Institute alongside KRiBSI?” Optimized for Project 20.
3. Polish public-sector agentic-flooding map — process/responsibility diagram plus a one-page resilience agenda, optimized for Project 14.
4. MCP specification matrix — optimized for Project 03.

Only after these are sound should time go to a Project 06 legal issue tree or a Project 07 space threat model.

C. A factual application inventory

Prepare a private note and populate it with concrete examples under these headings:

• education and relevant coursework;
• research methods used;
• policy, legal, technical, or public-sector experience;
• software and data skills with concrete examples;
• publications and writing links;
• examples of self-directed work;
• examples of reliability over a multi-week project;
• career direction and why SPAR is the next useful step;
• honest weekly availability and timezone overlap.

Use this as source material, not as text to paste into every application.

Start with the following verified narrative, then add specifics:

• trained and worked in law, including service as a judicial associate in a Polish court;
• transitioned into backend software engineering and now works primarily with Java/Kotlin and Python;
• understands production concerns such as permissions, APIs, data flow, observability, failure handling, and maintainability;
• independently studied modern ML and mechanistic interpretability through ARENA and Neel Nanda’s materials;
• wants to work at the boundary between technically informed AI governance and legal/institutional design.

For every statement, add one concrete example. Avoid presenting the career transition as a list of credentials; explain the judgments it enables that a single-discipline applicant may miss.

7. Eighteen-day execution schedule

If Day 1 is 31 July 2026, Day 18 is 17 August 2026. Adjust the dates if starting later. Confirm the actual submission deadline and timezone immediately; do not assume “18 days” includes the full final day.

The writing sample is the critical path. Protect the first nine days for it while using lower-energy time for institutional source collection.

Days 1–3 — lock the argument and sources

Day 1 — setup and exact scope

• Create the source matrix and application-answer tracker.
• Confirm the US federal doctrinal question, a specific offence or legally relevant mental-state context, and the selected interpretability method.
• Gather Rules 702 and 704(b), selected Supreme Court mens rea decisions, relevant US scholarship, Anthropic circuit-tracing material, and one primary technical paper.
• Write a 150-word provisional thesis and the evidence-chain diagram.
• Confirm the submission deadline, required form fields, and whether writing samples can be unpublished files or must be public links.

Day 2 — legal foundation

• Read the selected federal decisions and evidence rules.
• Write a 500-word doctrinal note containing only propositions that can be supported by authority.
• Record how Polish judicial experience informs research judgment without importing Polish doctrine into the US analysis.

Day 3 — technical foundation

• Read one circuit-tracing or attribution-graph paper closely.
• Extract method, output, validation, limitations, and alternative explanations.
• Write a 500-word technical explanation for a lawyer.
• Revise the evidence-chain diagram.

Checkpoint: a defensible thesis, complete outline, source matrix, and no unresolved confusion about what the interpretability method actually claims.

Days 4–7 — produce writing-sample version 1

Day 4

• Draft introduction, legal test, and paper roadmap.
• Draft the section explaining the interpretability method.

Day 5

• Draft the inferential bridge from technical evidence to the legal proposition.
• Address whether the relevant legal subject is the AI system, a human actor, or both; do not let this expand into a full personhood paper.

Day 6

• Draft reliability, expert-evidence, reproducibility, and counterargument sections.
• Add a concrete hypothetical showing how the evidence would and would not affect a case.

Day 7

• Complete the conclusion and research agenda.
• Cut the paper to 1,500–2,000 words.
• Audit every sentence as fact, authority, inference, or proposal.

Checkpoint: complete version 1 of the primary writing sample.

Days 8–9 — review cycle and Poland research

Day 8

• Self-edit the writing sample using the final rubric.
• Send it to one legally trained and one technically trained reviewer with three precise questions each.
• Draft the 500-word Project 15 critique and 300-word research-question answer while the full argument is fresh.

Day 9

• Read the Polish AI implementation act, KRiBSI provisions, Poland’s AI policy, and the official descriptions of UK AISI, the European AI Office, and Japan AISI.
• Start the four-institution comparison table.
• Outline the “KRiBSI versus AISI” memo.

Days 10–12 — Poland/EU institutional applications

Day 10 — Project 20

• Complete the comparison table.
• Draft both 300-word application answers.
• Draft the one-page memo: “Does Poland need an AI Safety Institute alongside KRiBSI?”

Day 11 — Project 14 research

• Map agentic flooding in a Polish court or administrative process.
• Identify submission channels, legal duties, capacity bottlenecks, safeguards, ownership, escalation, and access-to-justice risks.
• Draft the process/responsibility diagram.

Day 12 — Project 14 writing

• Draft the 100-word project focus.
• Draft the 200–400 word readiness assessment.
• Produce the one-page resilience agenda.
• Add a small Python queue model only if the prose and diagram are already complete and the model clarifies a real trade-off.

Checkpoint: Projects 20 and 14 have complete first drafts and concrete supporting artifacts.

Days 13–14 — governance exposition and standards

Day 13 — Project 13

• Draft the 400–500 word EU AI Act explainer.
• Draft the 300-word durable-versus-current layer answer.
• Prepare the ≤100-word writing-sample description.

Day 14 — Project 03

• Read the selected MCP specification sections closely.
• Complete the normative-requirement and political-implication matrix.
• Draft the 200-word forum answer and 350-word protocol analysis.

Day 15 — one backup only

Choose based on remaining energy and prerequisite fit:

• Preferred: Project 06 RQ2 legal issue tree and 300-word answer, if the degree prerequisite is plausible.
• Alternative: Project 07 system diagram, attack tree, and two application drafts.

Do not attempt both unless the primary applications are already strong.

Day 16 — integrate the full packet

• Complete biographical, motivation, availability, and career-direction fields for every primary application.
• Tailor the same experience differently by project; do not paste an identical personal statement.
• Check all links and contribution disclosures.
• Confirm that each application demonstrates the work that particular mentor requested.

Day 17 — feedback and adversarial review

• Incorporate reviewer feedback into the writing sample.
• Read each application as a skeptical mentor and list the three most likely rejection reasons.
• Fix the strongest objections.
• Verify legal and institutional claims against primary sources.
• Score every answer with the final rubric.

Day 18 — final buffer and submission

• Perform final word-count and formatting checks.
• Open every external link in a private/incognito window to confirm access.
• Export or publish the writing sample in the required format.
• Submit primary applications first: 15, 14, 20, 13, then 03.
• Submit Project 06 or 07 only if its application meets the same quality bar.
• Save a local copy of every final answer and confirmation.

If daily time is limited

Preserve work in this order:

1. Project 15 writing sample and answers.
2. Project 14 answers and process map.
3. Project 20 answers and comparison table.
4. Project 13 answers.
5. Project 03 answers.
6. Project 06 RQ2.
7. Project 07.

8. Final review rubric

Score every answer from 0 to 2 on each dimension:

Dimension	0	1	2
Directness	Does not answer	Answer is delayed/qualified	Clear answer in opening
Specificity	Generic	Some examples	Concrete mechanism, actor, and evidence
Accuracy	Unsupported	Mostly sourced	Primary sources and precise caveats
Reasoning	Assertions	Partial causal chain	Explicit mechanism and alternatives
Counterargument	Missing	Token objection	Strong steelman and resolution
Project fit	Reusable anywhere	Mentions project	Demonstrates exact work the project requires
Independence	Interest only	Proposed direction	Scoped method and credible deliverable
Style	Dense or vague	Understandable	Concise, structured, professional

Revise any answer scoring below 12/16.

9. Decisions made and remaining checks

Decisions made

• Project 15 is the lead application.
• Projects 14 and 13 move from Tier 2 to Tier 1.
• Project 03 moves from Tier 3 to Tier 2.
• Project 14 uses Poland, with agentic flooding of courts/public administration as the proposed focus.
• Project 20 uses Poland/KRiBSI as the middle-power institutional case.
• Project 15 uses a narrow US federal-law anchor, with Polish/EU experience as comparative context.
• Project 06 is limited to RQ2.
• The primary writing sample concerns mechanistic interpretability, US federal evidence law, and mens rea.
• Tier 5 remains excluded.

Checks to resolve on Day 1

• Exact application deadline, timezone, and submission mechanics.
• Whether the legal degree satisfies Project 06’s stated Master’s/PhD preference.
• Whether an unpublished PDF or shared document is acceptable as a writing-sample link.
• Which legally trained and technically trained reviewers can return comments by Day 9.
• Whether any professional confidentiality limits examples drawn from court or engineering work. Use only generalized, non-confidential examples.