Validation

This is the only page that states loomster’s status. Other pages link here rather than repeat it.

By tier and target

Each tier on each target: the Floci emulator and a real AWS account.

Tier	Floci	Real AWS
light	All seven stacks CREATE_COMPLETE, including the agents wave on Floci; the local app runs with a real Cognito login (just local-up)	Deployed end to end: the ALB serves Loom, backed by RDS and Cognito, and the backend passes its health check. backend/deploy-agent deployed an agent through Loom’s API to READY on this tier
production	All seven stacks against a bring-your-own VPC, with every tier resource: RDS Proxy, PrivateLink, ACM and Route53, backend autoscaling, the assistant runtime (just production-floci-e2e)	All seven stacks CREATE_COMPLETE on a custom domain over HTTPS, the assistant runtime READY on AgentCore, and the 15 screen checks the harness had at the time passed through a token from an MFA-enforced pool (just production-live-e2e)
production-ha	As production, plus Multi-AZ RDS, rotation and the two-task floor (just production-ha-floci-e2e)	All seven stacks, Multi-AZ RDS and the rotation schedule live, served over HTTPS, the assistant READY. It ran as a second instance next to production in the same account

Floci runs RDS as one container, so MultiAZ is requested and reported false, and it doesn’t serve the ALB to ECS path, so the health check only runs on AWS.

Recorded claims

Each claim runs twice: plain, where it must pass, and under BREAK=1, where it breaks its own property and must report caught. just claims records every run in test/claims-record.json, and npm run claims:page writes the table below from it; the docs check fails when the two disagree. Each cell is the claim’s own one-line verdict from its latest recorded run. bash test/claims.sh --list prints every claim with its target and statement.

Claim	Target	Plain	BREAK	Recorded
agents/per-agent-role	aws	pass: loom-agent-role made loom-claims-c633b8-agent-role-loomster-claim-c633b8-role and registered it in Loom (loom:group loomster); an agent on it reached READY in 322s and answered one invoke	fail: with bedrock model calls denied to the per-agent role, the agent still reached READY and answered	2026-10-13, 135fdea
agents/ready-and-invoke	aws	fail: the invoke streamed an error: data: {“error”: “No configuration found. Set AGENT_CONFIG_JSON or AGENT_CONFIG_PATH.”, “error_type”: “ValueError”, “message”: “An error occurred during streaming”}	caught: with bedrock:InvokeModel* denied to the runtime’s role: the invoke streamed an error: data: {“error”: “No configuration found. Set AGENT_CONFIG_JSON or AGENT_CONFIG_PATH.”, “error_type”: “ValueError”, “message”: “An error occurred during streaming”}	2026-10-13, 135fdea
backend/deploy-agent	aws	pass: Loom deployed loomster_claim_c49490_run_1791822788 to READY in 306s on us-east-1 and it answered one invoke	caught: with the task role denied: agent loomster_claim_c49490_brk_1791823177 ended FAILED after 46s (failed)	2026-10-12, bd7ac01
backend/deploy-agent-floci	floci	no recorded run	no recorded run
backend/task-role	static	pass: allowed=82/82	caught: dropped=iam:PassRole denied=6/82 hit=iam:PassRole@role/loom-dev-a-shared-foundation-agent-role	2026-10-12, dcbfca4
cognito/user-client	static	pass: light, production and production-ha: the user client allows password sign-in, and every frontend build passes its id from loom-cognito’s oUserClientId	caught: with a shared pool that names no user client: light: a loom-frontend docker-build lacks VITE_COGNITO_USER_CLIENT_ID from loom-cognito’s oUserClientId; production: a loom-frontend docker-build lacks VITE_COGNITO_USER_CLIENT_ID from loom-cognito’s oUserClientId; producti…	2026-10-12, 12a1d76
db/baseline	aws	fail: just db reader failed: no pg_hba.conf entry for host “10.0.1.162”, user “loom”, database “loom”, no encryption	fail: BREAK could not be applied: just db reader failed: db: 127.0.0.1:15432 is already in use; set LOOM_DB_LOCAL_PORT	2026-10-13, 135fdea
db/migrate-local	floci	pass: baseline recorded, the loomster_claim_probe_1791845574 migration stopped at its gate (exit 3), applied after its plan was approved, and status and drift are clean	caught: with agents.description changed out of band, just db drift reported it (exit 2)	2026-10-12, dcbfca4
local/auth	floci	pass: the SPA logs in at /floci-cognito/ and Loom accepts the Floci token (200 with g-admins-super; 401 without one)	caught: with LOOM_COGNITO_ENDPOINT_URL unset, Loom refused the Floci token (401)	2026-10-12, dcbfca4
ops/bootstrap	aws	pass: both service-linked roles exist after loom-bootstrap, and the second run found both and created nothing	caught: with iam:CreateServiceLinkedRole refused and no role present, loom-bootstrap failed with AccessDenied	2026-10-12, dcbfca4
params/reach-build	static	pass: the password reached loom-db and ARM64 reached the backend task definition	caught: with the variables unset: LOOM_DB_PASSWORD not in loom-db; LOOM_CPU_ARCHITECTURE=ARM64 not in loom-backend (CpuArchitecture X86_64)	2026-10-12, 12a1d76
params/reach-deploy	static	pass: the template cfn-deploy got for loom-db was synthesized in the run and holds LOOM_DB_PASSWORD	caught: with LOOM_DB_PASSWORD unset: LOOM_DB_PASSWORD is not in the template cfn-deploy got	2026-10-12, 12a1d76
screens/all	aws	fail: loom-seed (demo) failed: Op “loom-seed” failed after 24.0s	fail: BREAK could not be applied: loom-seed (demo) failed: Op “loom-seed” failed after 23.7s	2026-10-13, 135fdea
seed/demo-loud	floci	pass: loom-seed’s demo profile exited 0, and agents, memories, MCP servers and A2A agents each list an entry	caught: with the A2A card URL on a closed port, loom-seed’s demo profile exited non-zero	2026-10-12, dcbfca4
teardown/covers-components	static	pass: all 7 components are in the teardown order, consumers first	caught: with loom-agents dropped: not in the teardown order: loom-agents	2026-10-12, 12a1d76
tier/light-live	aws	pass: http://loom-claims-c633b8-shared-458efb-646878298.us-east-1.elb.amazonaws.com serves the SPA with the user client 70860og0bk9auhsvgieu9qriku baked in; signing in through it gave a g-admins-super token that /api/auth/me and /api/agents accept (401 without one)	caught: without g-admins-super the web app’s sign-in gave a token (groups [“t-admin”]) that /api/agents refused (403)	2026-10-12, dcbfca4
tunnel/rds	aws	pass: the tunnel host i-0754858d6479074b1 came online in SSM and scripts/tunnel.sh forwarded 127.0.0.1:61577 to the database, where SELECT 1 answered	fail: with the host’s ingress on sg-061ab6fd637417540 revoked, SELECT 1 still answered through the tunnel	2026-10-13, 135fdea

Not shown on any target

Each item below has a claim written for it, named in brackets. The five AWS claims among them have recorded runs, but those ran before the fixes for what they found (the memory namespace in the demo seed Op, the assistant’s baked config, SSL to RDS, and claims that mistook a streamed error for an answer). They haven’t run since, so their rows above show the old failures.

• Every screen check passing against a seeded Loom on AWS, the Evaluations seed steps included (screens/all). The Skills steps need an Agent Registry, which the claims deployment doesn’t configure.
• Chant-managed runtimes on AgentCore Runtime V2 answering an invoke live (agents/ready-and-invoke).
• The per-agent role from loom-agent-role being the one that limits the agent’s model calls (agents/per-agent-role). The plain run passed.
• The SSM tunnel failing closed when the host can’t reach the database (tunnel/rds; the plain run passed), and the SQL Yodeler baseline recorded through it (db/baseline).
• Real agent reasoning on Floci: invoking an agent there returns a canned reply.
• The bedrock-mantle:CreateInference grant against a mantle-only model.
• The generated Forgejo and GitHub deploy workflows against real infrastructure; their component pipelines run against Floci (just github-runtime-e2e, just forgejo-runtime-e2e).