tegwick
9c7c1e4bdf
Inbound demand against ITC-CAP v0.1.0 from a consumer that has completed a full
procurement-to-control cycle on a real resource. Three findings.
A. typical_resource_classes contradicts the model's own §4.11 ("consumption
attaches to a provision, never to an abstract capability") and carries almost
no information: 29 of 41 capabilities declare an identical C,S,N,P.
B. Quality targets have a supply-side home (ITC-LAND SLOs attach to services) and
no demand-side home. CapabilityRequirement is a capability id plus a minimum
maturity, so a consumer cannot state RPO, retention, or failure-domain
separation before a provider exists — even though ITC-CAP already declares
isolation and geographical_separation as data.backup dimensions.
C. The resource-class set has no human-effort class, and classifies Intelligence
as one more purchased input. Consumer evidence: provider selection inverted on
operator hours (Hetzner cheaper on infrastructure, EUR 29.14/month worse
overall); a self-managed option rejected on recurring hours rather than price;
and a platform repository that delivered effort in hours and explicitly not in
EUR. The consumer argues further that machine intelligence is a substitute for
human effort rather than an ingredient beside it, and that token efficiency is
a primary platform characteristic, so both need native units on a provision.
Also records the criterion used to reject splitting ITC-CAP into supply and
demand canons: split when the sides disagree about what exists, keep one canon
when they agree about what exists and differ only in what they assert about it.
Notes honestly that the consumer does not yet measure token consumption; that
part of the demand is forward-looking. It also offers the backup case, restated
in canon terms, toward ITC-CAP §10 promotion requirement 3.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|---|---|---|
| .claude/rules | ||
| .forgejo/workflows | ||
| demand | ||
| incoming | ||
| infospace | ||
| registry | ||
| seeds | ||
| spec | ||
| src/info_tech_canon | ||
| tests | ||
| trf | ||
| wiki | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| canon.yaml | ||
| CHANGELOG.md | ||
| CLAUDE.md | ||
| CODING_AGENT_BOOTSTRAP.md | ||
| INTENT.md | ||
| LICENSE | ||
| Makefile | ||
| pyproject.toml | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.md | ||
Building interoperable, adaptable, and extensible information-processing systems.
Current Service
This repository now implements one concrete infospace under infospace/.
The repository root remains the service, governance, and workplan shell.
The first service surface is intentionally small:
- JSON-first CLI commands
- importable Python service functions
- read-only local HTTP API
- artifact loading, checks, and graph summaries backed by
infospace-bench
Source-Tree Usage
PYTHONPATH=src python3 -m info_tech_canon inspect
PYTHONPATH=src python3 -m info_tech_canon artifacts
PYTHONPATH=src python3 -m info_tech_canon models
PYTHONPATH=src python3 -m info_tech_canon standards
PYTHONPATH=src python3 -m info_tech_canon review-kit
PYTHONPATH=src python3 -m info_tech_canon alignment-template
PYTHONPATH=src python3 -m info_tech_canon validate
PYTHONPATH=src python3 -m info_tech_canon graph
PYTHONPATH=src python3 -m info_tech_canon index
PYTHONPATH=src python3 -m info_tech_canon views
PYTHONPATH=src python3 -m info_tech_canon profile inspect small-saas
PYTHONPATH=src python3 -m info_tech_canon profile validate small-saas
PYTHONPATH=src python3 -m info_tech_canon profile graph small-saas
PYTHONPATH=src python3 -m info_tech_canon api --host 127.0.0.1 --port 8765
After package installation, the same commands are available through the
info-tech-canon console script.
API Endpoints
GET /healthGET /inspectGET /artifactsGET /artifacts?kind=modelGET /modelsGET /standardsGET /review-kitGET /alignment-templateGET /validateGET /graphGET /graph?format=mermaidGET /viewsGET /views/{name}GET /profiles/{profile}/inspectGET /profiles/{profile}/validateGET /profiles/{profile}/graph
Maintenance
make validate
make index
make tree
make agent-briefs
First Profile Proof
The first executable profile proof is small-saas. It lives under
infospace/profiles/small-saas/ and includes connected example artifacts for a
tenant-aware SaaS service: service, system, tenants, user, team, dataset,
deployment, task, policy, control, evidence, and incident.
Agent Retrieval
Agent-facing retrieval assets live under infospace/agent/:
global-agent-brief.mdretrieval-index.md,retrieval-index.yaml, andretrieval-index.json- per-artifact briefs in
agent/briefs/ - consumer brief templates in
agent/consumer-briefs/ - Canon Interface Card template in
agent/templates/ - consumer alignment review kit in
agent/review-kit/ - consumer alignment workplan template in
agent/templates/
Alignment Reviews
The consumer alignment review kit lives under infospace/agent/review-kit/.
It provides a repeatable workflow, model and standard selection guide,
scorecard, structured review schema, and repo-local workplan template so agents
can review consumer repositories against the canon without mixing consumer work
into this repo.
Purpose And Demand
The PURPOSES candidate model is registered as a governance extension at
infospace/models/governance/InfoTechCanonPurposeDemandExtension.md. It defines
consumer purposes, demand signals, purpose fit, scope pressure, and evolution
requests so consumer demand can inform repo governance without silently changing
producer scope.
Evaluations
Canon-side evaluation packs live under infospace/evaluations/. The first pack
is user-engine, which prepares pre-integration assessment of a user-management
capability against Organization, Access Control, Governance, Data, Security,
Task, PURPOSES, CARING, and the small-saas profile.
railiance-fabric adds conformance support for graph-oriented entity and edge
capture, including mapping expectations and visualization examples that separate
canonical relationships from display-only graph edges.
repo-scoping adds a canon comparison and extension pack for repository intent,
current scope, future scope, consumer purposes, review decisions, evidence,
source observations, utility relationships, scope freshness, and SCOPE.md as an
interface profile. The pack is intended to seed the consumer-side repo-scoping
workplan while keeping proposed canon extensions reviewable.
Benchmarks
CARING benchmark assets live under infospace/standards/caring/benchmarks/.
The first benchmark is kubernetes-rbac, which maps Kubernetes RBAC native
constructs into CARING descriptors and records canon pressure around native
roles, effective access, derived workload capabilities, induced secret exposure,
and the rule that a Namespace is not automatically a tenant boundary.