Skip to content
TapPass Internal

Components

Components

Section titled “Components”

One file per buildable unit. Each component file is self-contained: vision context + spec + acceptance criteria + dependencies. A subagent dispatched to "implement X" opens its component file and finds everything it needs in one place.

Three views, same components

Section titled “Three views, same components”
  • This file (Question view) — components nested by the architecture-doc question they answer. Best when you own a user-facing concern ("I own compliance authoring").
  • SYSTEMS.md — components grouped by engine/subsystem (Policy engine, Tool governance, Sandbox runtime, Sync system, Operator surfaces, Evaluation, Reference impls, Trust & compliance). Best when you own a technical engine ("I own the policy compiler").
  • DATA-OBJECTS.md — components organized around the eight first-class data objects (Policy, Sandbox, Keyring, Tool, Audit, Probe, Identity, Authoring sub-objects), with the engines that operate on each plus the quick-start templates. Best when you own a noun ("I own everything that touches Policy").

Pick whichever cut matches your scope. All three point at the same files.

How to use this folder

Section titled “How to use this folder”

You are a subagent who owns a component.

  1. Open <question-folder>/<component>.md. You'll find frontmatter at the top and six sections below.
  2. Read your frontmatter. parent_concept + parent_question give you the strategic context. depends_on and blocks give you the coordination context.
  3. Read your component's body. §1 is the vision. §2 is the contract. §3 is the design. §4 is the checklist. §5 is who else's work touches yours.
  4. Click into the parent concept's section if you need full vision context.
  5. Update the frontmatter as you progress: status, last_updated, spec_status, implementation_status.

You are an operator surveying current state.

The table below is the honest current snapshot of every component. To regenerate this from the frontmatter (when a script exists): tappass-components index --output README.md.

Index — current status

Section titled “Index — current status”

Components are nested by the architecture-doc question they answer. Each entry shows: id, status, size, owner, blockers (if any).

Q3 — What interactions do we govern?

Section titled “Q3 — What interactions do we govern?”
ComponentStatusSizeOwnerBlocked by
upstream-tool-proxyconceptMplatformpolicy-to-sandbox-config-builder
approved-tool-server-listconceptSplatformupstream-tool-proxy
resource-access-checkerconceptSplatformupstream-tool-proxy
runaway-agent-stopperconceptSplatformupstream-tool-proxy

Q4 — How is policy written, and how do regulations map?

Section titled “Q4 — How is policy written, and how do regulations map?”
ComponentStatusSizeOwnerBlocked by
eu-ai-act-bundleconceptMcompliancepolicy-to-sandbox-config-builder
owasp-llm-bundleconceptMcompliancepolicy-to-sandbox-config-builder

Q5 — How do business users actually use this?

Section titled “Q5 — How do business users actually use this?”
ComponentStatusSizeOwnerBlocked by
onboarding-wizardconceptSfrontendoperator-cli

Q6 — How does policy scale across an org with multiple teams?

Section titled “Q6 — How does policy scale across an org with multiple teams?”
ComponentStatusSizeOwnerBlocked by
cascade-merge-engineconceptMplatformprojects-teams substrate

Q8 — How do we know the agent obeys policy before we deploy it?

Section titled “Q8 — How do we know the agent obeys policy before we deploy it?”
ComponentStatusSizeOwnerBlocked by
pre-deployment-evaluatorconceptLplatformagent-client-sdk
owasp-llm-probe-libraryconceptMcompliancepre-deployment-evaluator

Q9 — How do we enforce policy on the host? (3 rings + 2 cross-cutting layers)

Section titled “Q9 — How do we enforce policy on the host? (3 rings + 2 cross-cutting layers)”

See q09-rings-and-cross-cutting/README.md for the layered model and how each catches what.

ComponentStatusSizeOwnerBlocked by
ring-kernelconceptMplatformhost-runtime-cli
ring-harnessconceptSplatformhost-runtime-cli
ring-interpreterconceptSplatformhost-runtime-cli
cross-cutting-mcp-broker(pointer)——(Q3 components)
cross-cutting-llm-gatewayshipped——(already in tappass/gateway/)

Q10 — How do we unify one policy across every layer?

Section titled “Q10 — How do we unify one policy across every layer?”
ComponentStatusSizeOwnerBlocked by
policy-to-sandbox-config-builderconceptLplatformtrust-engine-async, cascade-merge-engine

Q12 — How do we keep sandboxes in sync, and detect drift?

Section titled “Q12 — How do we keep sandboxes in sync, and detect drift?”
ComponentStatusSizeOwnerBlocked by
live-policy-push-channelconceptMplatformpolicy-to-sandbox-config-builder
behavior-drift-monitorconceptMplatformlive-policy-push-channel

Q14 — How do we manage three CLIs without confusion?

Section titled “Q14 — How do we manage three CLIs without confusion?”
ComponentStatusSizeOwnerBlocked by
operator-cliconceptMclipolicy-to-sandbox-config-builder
host-runtime-cliconceptMclilive-policy-push-channel, agent-client-sdk
agent-client-sdkconceptSclilive-policy-push-channel

Q15 — What does this look like for a real agent?

Section titled “Q15 — What does this look like for a real agent?”
ComponentStatusSizeOwnerBlocked by
collibra-reference-agentconceptMplatformupstream-tool-proxy, agent-client-sdk, host-runtime-cli

Operational (not a question — trust posture and audits)

Section titled “Operational (not a question — trust posture and audits)”
ComponentStatusSizeOwnerBlocked by
soc2-type1-auditconcept(calendar)opspublic-trust-page
public-trust-pageconceptSops(none)

Status legend

Section titled “Status legend”
  • concept — we agree this needs to exist; nothing started
  • spec — someone is writing the feature doc
  • impl — someone is writing code
  • shipped — running in production
  • deferred — decided not to do this quarter
  • (pointer) — this layer/component delegates to another existing component
  • (shipped) — capability already exists in TapPass codebase

Adding a new component

Section titled “Adding a new component”
  1. Copy _template.md to the right q<NN>-<name>/ folder.
  2. Fill in frontmatter completely. Do not skip depends_on, blocks, acceptance_criteria.
  3. Write §1 (vision context, ~100 words) immediately. The other sections can fill in as the component matures.
  4. Add an entry to the index above.
  5. If your component blocks/is-blocked-by another, edit that one's frontmatter too.